Re: language translator help

[John W. Eaton]

On 27-Apr-2002, Neil Jerram <address@hidden> wrote:

| >>>>> "John" == John W Eaton <address@hidden> writes:
| 
|     John> Although there has been much inactivity in the year or so
|     John> since I first asked this list for comments about the
|     John> possibility of some kind of Guile/Octave merger, I've not
|     John> given up.
| 
| That's good news; I'd love to see this idea succeed.  Would you like
| some help?

Yes, absolutely!  I am really a novice when it comes to Scheme, so I
could really use some pointers there.

|     John>  * improving the performance of Octave's interpreter
| 
| If Elisp is a guide, this will only happen if you make N Octave
| executions turn into 1 translation + N evaluations (for N>>1).
| Current Elisp experience is that 1 translation + 1 Guile evaluation is
| _slower_ than 1 native Elisp evaluation.

I think it performance might be better in most cases because Octave's
interpreter is known to be really slow for many operations.

|     John>  * allowing me to avoid having to maintain yet another scripting
|     John>    language interpreter (though it remains to be seen whether a
|     John>    translator will be any simpler than the current interpreter).
| 
| Yes, but two caveats here:
| 
| - You have to believe that implementing your language constructs in
|   Scheme is easier to maintain than implementing them in C.

Well, I'm not sure.  But it is a lot of work to write an maintain an
interperter for a special language, and much of that effort is
duplicated by every scripting language.  People using Octave and Guile
both want access to OS system calls and library functions (from basic
stuff to GUI toolkits) so it seems wasteful to me that we build many
interfaces to all these different libraries.  I think it would be much
better to take advantage of existing work that's already been done.

| - Because of the performance issue mentioned above, I'd say it's still
|   an open question whether you'll get adequate performance
|   implementing the language in Scheme.  You might end up wanting to
|   keep it in C anyway (but switch to using Guile data types).

Along with a way to call Guile functions, this would offer a lot, but
I would still like to get away from having to maintain the low-level
details of an interpreter.

|     John> Obviously, making the new system fully functional would
|     John> require not only writing the translator, but also creating a
|     John> run-time library of Octave primitives that could be called
|     John> from Guile.
| 
| Right, but this is just a matter of wrapping existing code, isn't it?

Yes and no.  There is the opportunity to correct some of the mistakes
of the past too, which might mean more than just wrapping the current
Octave classes.

|     John> For the Octave users who are more comfortable programming in
|     John> Octave rather than Scheme (and this includes me, at least
|     John> currently), having the translator is essential.
| 
| Totally agree; this is what Guile is supposed to be about: providing
| language flexibility to its users.

Yes, but there seem to be no fully functional examples of actually
doing this yet.  If that's correct, why not?  What's keeping people
from doing this?

One problem that I can imagine is that for languages like Perl, or
Python, which are starting to be quite large, it's not enough to just
translate the syntax to scheme, you need the run-time.  Integrating
all of that could be a lot of work.  But I think that a bigger problem
is that there is no standard for these languages, so the language
definition is whatever the real Perl or Python interpreters do today.
Unless the authors of those tools integrate the Guile interpreter in
their own code, the fork becomes difficult to maintain.

These sorts of problems would not cause trouble for Octave, because I
would be integrating Guile completely.  I'm just trying to understand
what might be the reasons that we don't have many translators.

|     John>  * Is it a good idea for the translator to parse Octave code and 
emit
|     John>    Scheme code as strings that are then reinterpreted by Guile?
| 
| This is what I'd begin with.  Performance-wise I can't guarantee it'll
| work out, but we have to try it and see.

I think this would be the simplest thing to start with, because it
would be easy to debug.  You could simply look at the Scheme code that
is generated and see whether it was correct.

Thomas Bushnell also suggested generating Scheme forms using cons
instead of writing ASCII text.  Can this be done easily from C for
every language construct?  If so, it seems that it would be easy
enough to switch to this method once the translate-and-emit-text
system works.

jwe