Re: Translators to guile

[Sebastian Andersson <bofh@diegeekdie.com>]

> And the big 3 scripters, i.e. perl, python and tcl, should also come asap,
> but perl and tcl have a syntax that are a pain in the tail to handle, let
> alone the semantics. The other string processing languages (m4, awk etc.)
> aren't much better. Somehow those string processing langs have yet an 
> important role in many GNU tools which are to be replaced with guile once
> possible: automake, autoconf, dejagnu on top of them.

Could someone explain why this is to happen?
I can understand that it would be nice if all GNU tools could use the
same extension language (like guile), but why do it in this way
(writing translators for every language)? Why not make a library that
sits between the aplications and the languages and use that for linking
aplications to extension languages and let the aplication (via some
config file perhaps?) choose the languages to load "behind" the API.
That way one would only have to make dynamicly loaded shared object that
could be loaded by the the new library instead of having to write
translators and adapting the translated language's extension mechanism
to be able to load it's extensions.

/Sebastian