This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
[RFC] Re: translators to guile
What I'm actually interested in is:
How will translators generally work?
Will I just be able to open a standard Python file? How?
Or do I need to add something? What?
************************************
If this isn't settled on yet, I have my own suggestion/proposal:
1. (load-generic filename)
This function would get ``filename'' trough an alist to find
the correct translator. This would require each translator to
register a loading function.
Perhaps if the filename criterium fails, we can try a second
alist with the first line of the file, or the results of
`file filename` or something?
Of course this sollution doesn't help a lot if people need to
evaluate a string. But then again there are probably no means
of finding out the language of a string, so an app that has
lots of tiny bits of script has to find its own way to find
out the language. Perhaps we could give them, just to be
nice, two extra functions: (language-list) with the list of
registered translators/reinterpreters, and
(eval-with-language string language) which I hope is
self-explanatory.
2. Reinterpreters
This is what I do with Sonya, a module to read postfixed
(currently FORTH, more or less) code. A script that uses a
reinterpreter isn't properly a target language script, and
yet it isn't exactly Scheme. All you have to do is add to the
top of the script a "(language foobar" line and a ")" to the
bottom. For example, a Sonya script with this system could be:
(language forth
2 2 + =
(Hello word!) =
)
As ``language'' is a syntax, we know we shouldn't interpret
parenthesis and other stuff inside. Do guile syntaxes know
about leaving comments alone? (Because what is a comment for
Guile may be a command for some other language)
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux -- http://www.debian.org