Re: [Gnu-arch-users] Status of global and tree aliases

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > I'm not addressing version variables at all. I think thats a
    > different issue.

Perhaps I haven't made myself clear.

You _are_ addressing version variables -- just not very well, with
lack of forsight, and incompletely.

Arch already has a few mistakes of the sort you are making now (all of
which are my fault) including but not limited to:

   ~ the format of =tagging-method
   ~ the format of ~/.arch-params/<almost-everything>
   ~ the format of $archive/=meta-info/*
   ~ the format of .arch-id/foo.id files
   ~ the format of checksum files in archives
   ~ the format of some of the log headers

There's considerable overlap in the requirements, now and in the
forseeable futrue, of all of those file formats.  Yet currently they
have mutually incompatible syntaxes and semantics and every one of
them is implemented by a separate bit of code.  A user (or program)
who learns how to set or read a parameter in an =tagging-method file
has learned nothing useful at all about, say, a file in
$archive/=meta-info.   Some of the formats (e.g., .arch-id/foo.id) are
difficult to extend in an upward-compatible way and we've already
encountered cases where that is an obstacle.

Now you want to add new code and a new format and you think this is a
good idea because, for your particular task, a very trivial format
will do.  Famous last words, if you ask me.

There's also the question of how your aliases will interact with
merging.  Under your design (though you later suggested maybe you'd
change this) merging is just via textual merges.  This seems to me to
be awkward, at best.  For example, merging a change from my "upstream"
where that change changes his "upstream" and other aliases will have
an undesirable effect: either silently replacing my "upstream" with
his or dumping a mess of conflicts in my lap to try to sort out.
Neither outcome seems at all necessary: a sane merge rule for aliases 
is not hard to imagine -- it just isn't likely to map onto textual
patching very well.

It seems to me that aliases, like some other parameters we can imagine
setting persistently during a commit, require (or at least greatly
benefit) from a little flexability about merging rules.   

You've also repeatedly expressed some hostility towards furth.  I'm
quite puzzled by that and am starting to wonder if this is just some
kind of personality conflict or whether you have a good reason to be
hostile.  So far as I know, you know almost nothing about furth.
Moreover, adding furth to tla can, in the medium term, result in less
and simpler code overall -- that should be fairly obvious.  It's
unclear to me why you are so hostile to furth so perhaps you could
explain your engineering reasons so that they can be either refuted or
conceded to.

Say, by the way, how many of these little one-off, half-assed tiny
languages do we need to add to tla before the total amount of code
dedicated to implementing them exceeds that of a single, good,
general-purpose solution?  I think it's already very clear that you
could implement xl0 with well under 10k lines of code.  I claim that
full xl will have the same property although I haven't shown that yet.
Furth itself does not aim to be _quite_ a minimalist VM framework for
implementing things like xl --- it is a tiny bit fancier than strictly
necessary.  I don't think it will be huge, though.   

It's such a no brainer to want to add a component that's _like_ furth
that I'm really quite stumped as to why you have a bee in your bonnet
about it.


-t