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

[Gary V . Vaughan]

On Thursday 12 April 2001 11:17 am, Akim Demaille wrote:
> >>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
>
> Alexandre> On Apr 11, 2001, Akim Demaille <address@hidden> wrote:
> >> We are about to write new tools, typically autom4te, on top of
> >> which autoheader, autoconf etc. will be rewritten.  I'm fed up with
> >> addressing portability issues on the maintainer side.
>
> 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.
>
> Your claim does not apply IMHO.

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

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

I used to like awk a lot, until I realised that it was actually only gawk 
that I liked, and half my users couldn't run my code.  However, the current 
GNU M4 CVS can do all this and more.  The downside is that someone has to 
write loadable modules in C to implement the functionality.  Since it uses 
libltdl, any modules required by autoconf can be preloaded on hosts that 
can't do dynamic loading.  I am on the verge of a 1.5 release, and have been 
for some time -- I just need to cleanup some ugliness in the code -- so there 
need not be an issue of relying on unreleased tools.  Autoconf already 
requires GNU M4, and all of the technology for generating shell scripts from 
m4sh is here.

> configure is not concerned by this.

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

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

Well, I still have my Sic project on the table.  I have a prototype for the 
runtime which will drastically improve the speed of shell scripts (at least 
an order of magnitude by my rough measurements).  The proof of concept for 
the front end will allow heavy users of portable shell (e.g. configure and 
libtool) to gradually migrate towards full sic syntax (i.e. functions, 
arithmetic, libc calls etc) without undertaking a rewrite in a whole new 
language.  The cost will be that projects will need to ship with, and compile 
the runtime before scripts will run -- much like we currently build libtool 
from shipped components inside the project.

There is one big problem with this two pronged (M4 modules + Sic) approach... 
I don't have much time to devote to Sic at the moment, and the code is not 
yet functional enough to attract more users, so it represents a long term 
commitment.

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

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc