[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.)


    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 

    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,

As Thomas says, other more explicit approaches are possible - you have
full control over how you translate an Octave variable reference.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]