Re: Perl vs Scheme vs ML vs ... for autoconf

[Akim Demaille]

>>>>> "Gary" == Gary V Vaughan <address@hidden> writes:

Alexandre> That's why we should have this portability library coded in
Alexandre> m4sh.  Instead of repeatedly fixing the same problems over
Alexandre> and over, we should have them coded right once, and then
Alexandre> used all over.  This will not only document the portability
Alexandre> problems and solutions, but also make it easier for us to
Alexandre> fix problems whenever they're found, reduce the learning
Alexandre> curve of candidate new maintainers, and introduce new
Alexandre> foundations for portable scripting.

Akim> Your claim does not apply IMHO.

Gary> I must say that it rings very true for me...

I indeed overstated here, but actually that sentence was not meant to
be read alone.  I really meant that I agree it applies but not _here_,
because it has become more a burden than a good thing.  For simple
drivers, I agree it is a fine exercise to try to do it in sh, but
seriously it is responsible for too many problems.

Let me shift the discussion onto another context.

Why do we all program in C?  (please, don't argue on the `all' here,
I'm just simplifying).

Because we aim at portability in the sense that it's the least we can
have on the users' machines.

Now I'm saying ``we work here for people who are expected to have
decent environment, let's go for Ada or Caml'', and you tell me
``beware, you might loose your portability skills''.

I agree I'm exaggerating, but that's nonetheless pretty much what
happens here.

I'm tired of living in the 70's.  I wish I could concentrate on my
features instead of others' misfeatures.  I wish I could provide
better tools, without wasting my time discovering other problems *just
because we decided to work in bad conditions*.

Also, my ``this does not apply'' refer to the fact that the
assumptions for autoconf.sh are by far weaker than those on
configure.  E.g., awk.  autoconf.sh is not the proper place to learn
about programming configure.

The assumption for autoconf.sh is, and will remain, sane environment.
The assumption for configure is, and will remain, hell.


>> The recent bug reports about autoconf.sh are exactly what I'm
>> referring too: AWK is too weak a language for us to test the
>> existence of a file, and AWK implementations disagree on what to do
>> in such a case.

Gary> I used to like awk a lot, until I realised that it was actually
Gary> only gawk that I liked, 

I have been beaten by the same problem.

I *don't care* about learning that you cannot call `function (this)',
because it's not portable.  I don't care knowing that

function (foo)
{
   ....
}

is portable, but

END
{
  ...
}

is not.  This is just polluting my brains.  I don't care about this at
all.  Worse yet: it is a *bad* thing, because some maintainers can
trust the tools I deliver, just because it has been decided we should
continue building applications with, basically, |, && and ||.

We are exposing us and the users (= maintainers here) for *free*.
Just for the beauty of the act!  Art comes from constraints!

Tsa!  Puke puke puke.  We are engineers, we choose the tools that are
adequate (when we are free to).

>> configure is not concerned by this.

Gary> ??  I assume you mean autoconf should not need to worry about
Gary> this.

Sorry I was unclear, I was referring to what I detailed above:
configure does not care about the awk portability issues, since it's
just forbidden.  (note that autoconf uses 2nd generation AWK, aka,
nawk, which is something configure cannot yet expect.  AWK 1 is OK
though, IMHO).


>> Because we need more, there is no reason to remain bound to sh.

Gary> Well, I still have my Sic project on the table.  I have a
Gary> prototype for the runtime which will drastically improve the
Gary> speed of shell scripts (at least an order of magnitude by my
Gary> rough measurements).

That's a fine project!  But as a target language (= configure).  I
fail to understand why I should remain bound to sh for autoconf.


Gary> Although Perl offers the path of least resistance, I am not at
Gary> all convinced that it will prove to be the correct choice in the
Gary> fullness of time.

That's another debate.  

I *agree*.  

I'd rather use Python, Guile, or indeed, Caml.  But that's pushing the
requirement over maintainers a bit too high for 2001.  IMHO.

And in the fullness of time, none of these too btw :)
(But Autoconf will still exist! ;)