a) automake was not ported from perl to guile for years,
and I don't know of experiments to actually do it now,
or have it done in this decade (it wasn't in the last).
Moving it from perl to guile does not earn much for
features or maintainability - it would just be another
point to spread guile which I suspect to be one of
the intents for RMS to propose it ;-)
b) perl is nice for its builtin regex, string-ops and
system-support supported with syntactic sugar. It has
an easy learning curve which gave it a good audience,
Using perl for autoconf.* feels natural - you want to
search, extract and write things, and the best thing
to use is a Practical Extraction and Report Language.
The syntactic sugar however does sometimes confuse
people which is the downside of TMTOWTDI.
c) a + b plus perl being ubiquitous - what else, hmmm..
d) if you ask for a language that had been forgotten,
I'd point to php which is an original for string and
database too, and with the advent xml era, it show
an enormous growth, just like python in its first years.
However, I feel it is still "evolving" in the sense
it could shiftshape where perl is pretty done now.
e) autoconf.* maintainerscripts look short, I have to admit
that I don't get the idea of changing things. And if so,
use the scripter that people are fluent with. You have
automake.pl aclocal.pl autoupdate.pl, and automake.pl is
bigger that the sum (!!) of the other auto*-tools. That's
an argument to let converge maintaince on both sets of
the autoconf/automake theater.
just my 2cent,
-- guido Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- h.r(*@)>+++ y++ 5++X-
