Re: [Gnu-arch-users] Tla spork

[Zenaan Harkness]

>     > ~/.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"))

Just as an aside, I find this parens-encased data format to be quite
intuitive, and very appealingly shorter (and more consistent and easier
to learn) than XML 'tags'.

It's just prefix-based mathematical/ logical expressions that jar
my thought process.

Quick question: what exactly does s-exp stand for??

> 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.

If it means consistency across config files, I wouldn't call it
overkill (I'd call it consistency :)

> 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.

If you call the above overengineering <cough>XML</cough>,
I say go for it!

> (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.)

Tom, you keep saying things that draw my interest level up no end.
It's almost frustrating/ excruciating at times.
Please do keep us informed...

cheers
zen