This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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