[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: language translator help
From: |
Neil Jerram |
Subject: |
Re: language translator help |
Date: |
27 Apr 2002 10:48:12 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "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?
(Background: I recently wrote the prototype Elisp translator in CVS
unstable, so I have a little relevant experience.)
John> Right now, my ideas are that I would eventually modify
John> Octave's parser to emit Guile code, and then pass that off
John> to Guile to interpret. My reasons for wanting to do this
John> include
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.
John> * immediately gaining some functionality that would otherwise be hard
John> to get (object-oriented programming with goops, an interface to
John> external packages like gtk, etc.)
Absolutely.
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.
- 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).
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?
John> As I see it, adapting Octave's core functions (the stuff
John> written in C, C++, and Fortran) for use with Guile is a big
John> job, but one that is certainly possible. Even just having
John> that capability inside of Guile would probably be quite
John> useful to some.
(use-modules (octave)) - would be wonderful.
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. And who knows, it may turn out
that the Octave language syntax is convenient for tasks unrelated to
mathematics, too.
John> Before jumping in and doing a lot of coding, I'm trying to
John> get a clearer idea about how the translation would work.
John> Some questions:
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? Is
John> there a better way of doing that? My guess is that this is OK, and
John> the overhead of parsing twice is not so important.
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.
John> * I originally thought that translating the syntax would be trivial,
John> but now I find that I'm really quite clueless when it comes right
John> down to doing this part.
John> For example, Octave has C-like break and continue statements for
John> breaking out of or jumping to the end of a loop. What is a
John> reasonable way to translate them to Scheme? I came up with a way
John> to handle both, but they involve call/cc and seem much more
John> complicated than the corresponding Octave code. I'm left thinking
John> that there must be a better way. However, solutions that
John> completely rewrite the structure of the loop are not so interesting
John> to me unless there is a way to do that in a way that doesn't
John> require the translator to do a lot of analysis of the incoming
code.
John> Can anyone offer some clues about these kinds of translation
John> problems? Failing that, is there a "Scheme for C Programming
John> Dummies" kind of document somewhere?
I'm not aware of such a document. Suggest you post the translation
code that you've tried already. I'll certainly take a look, and I
guess you'll get a deluge of suggestions from others as well.
John> * If syntax can trip me up, I know semantics will too. For example,
John> it's not clear to me how to handle the differences in Octave and
John> Scheme scoping rules for variables.
What are the Octave scoping rules? For dynamic scoping (a la Elisp),
Guile has the address@hidden' macro for setting and restoring such variables'
values. In the Elisp case, this allows Elisp variables to be Guile
variables directly. (Except that it doesn't cope with buffer-local,
etc.)
As Thomas says, other more explicit approaches are possible - you have
full control over how you translate an Octave variable reference.
Regards,
Neil
- language translator help, John W. Eaton, 2002/04/26
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/26
- Re: language translator help,
Neil Jerram <=
- Re: language translator help, John W. Eaton, 2002/04/27
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/27
- Re: language translator help, John W. Eaton, 2002/04/27
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/27
- Re: language translator help, John W. Eaton, 2002/04/28
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/28
- Re: language translator help, John W. Eaton, 2002/04/28
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/29
- Re: language translator help, John W. Eaton, 2002/04/29
- Re: language translator help, Thien-Thi Nguyen, 2002/04/29