Re: [Gnu-arch-users] Tla spork

[Tom Lord]

    > From: Matthew Dempsky <address@hidden>

    > Tom Lord <address@hidden> writes:

    > > One of my concerns is, of all things, about the syntax of new files
    > > that you add.   Can you please present the syntax of "/id" files?
    > > (I know, I know... it sounds like such a nebbishy detail but, as I
    > > suspect *you* know.... these are the kinds of details that *really*
    > > matter in the longer term.)

    > ~/.arch-params/hats/$HAT/id is the same format as ~/.arch-params/=id.
    > The id selection is taken care of in arch_my_id_file (I think) by
    > returning the former if a hat string is passed and the latter if nil
    > is passed.

    > Is it preferable to break it into ~/.arch-params/hats/$HAT/name and
    > /uid (or /email)?


My thinking has been that we should probably start consistently using
s-exp based syntaxes and making sure that they pun as something that
could be a macro.   That way, among other wins, we have less worry
about extending the syntaxes in the future.   Something like:


        ~/.arch-params/hats/$HAT/id:

        (arch-user "Tom Lord" "address@hidden")

or maybe as a tagged alist:

        (user-params  (name "Tom Lord")
                      (id "address@hidden"))

Yes, that's overkill for just this one file but some of the other
changes coming up for ~/.arch-params involve restructuring and
increasing the amount of structure to other data (e.g., the "table
design" for archive registries has lots of fields, some of which
contain lists, etc.)  I think that, therefore, we'll want "tla/libawk"
to be a lot more serious --- basically to be just the data-structure
foo from xl plus relational operators on top of that.

I'd say overengineer this particular file format just a bit in order 
to have the relevent tools around for the next N file formats.
(XL is missing a reader, currently --- there's a vestigial (not up to
date) version of one a few revisions back --- not sure whether it's
worth picking up that or just knocking out a quick one from scratch.

(Ultimately, xl readers and awk-like relational routines should be
coded in a very strange style so that they work with the VM in a nice
way but, here for arch, very simple versions in traditional C style
(comparable to libawk) are appropriate.)


-t