This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
RE: Guile & Octave (was Re: Docstring question)
- To: David Lutterkort <lutter at cise dot ufl dot edu>,"'John W. Eaton'" <jwe at bevo dot che dot wisc dot edu>
- Subject: RE: Guile & Octave (was Re: Docstring question)
- From: "Daschbach, John L" <John dot Daschbach at pnl dot gov>
- Date: Fri, 10 Dec 1999 11:02:17 -0800
- Cc: 'GuileList' <guile at sourceware dot cygnus dot com>
From: John W. Eaton
My idea was to translate Octave/Matlab code to guile. As I understand
it, I would need to create a way to handle Octave values and call at
least some of Octave's functions from guile. Octave's parser
currently creates a parse tree that I think could be used to generate
equivalent guile code, so my idea was to just use the current parser,
not to try to write a new parser for Octave syntax in guile. Once the
parse tree has been converted to the equivalent guile code, it could
be evaluated by the guile interpreter.
My thinking was more along the lines that the octave interpretter would embed a
guile interpreter and include the glue to pass data back and forth between them.
In the simplest approach you would not be able to interleave calls, i.e. if in
octave you called guile
oct_array = eval_guile("(find-matching-data template)");
there would be no way for the 'eval_guile' to call octave.
Another useful approach would be to enable the octave library to be linked with
guile and write the smobs and C functions to call the octave library. This
would only of course cover the core numerical functionality of octave, leaving
out the code that resides in .m files. After this the issue of converting .m
code into guile code could be addressed. It is likely that some octave
constructs would translate into either obtuse or inefficient scheme code, and
some new guile code (eventually in C) would be required.
I would also like to be able to write modules in guile itself. If
that were possible, then perhaps Octave could also take advantage of
other guile libraries using either guile syntax or Octave/Matlab
syntax.
Octave could take advantage of guile using the first approach. Guile could take
advantage of octave using the second.
Though it might be nice, I'm not sure it would really be necessary to
create a new syntax for index ranges. Translating Octave code to
guile would only require some function that could do the work. Slick
syntax wouldn't really matter much, though it might be nice to have
for writing matrix-oriented code directly in guile.
Yes, I don't ever see straight scheme being able to employ the syntactic sugar
that octave uses. It would require an entirely different reader. A true
guile-octave would require it's own syntax, different from both scheme and
octave.
Some things that are preventing any of this from happening are a lack
of time and funding. There are many other projects for Octave that
have a higher priority now. For the people who currently pay the
bills, making Octave work with guile has a much lower priority than
improving its numerical tools. Also, I don't really know scheme or
guile (yet) so that presents a bit of a barrier for me doing the
work myself. However, if someone is really interested in this kind of
project, let me know. I can probably help you get started
understanding how various parts of Octave work.
At some point I might try and link octave with guile, but my prefered use would
be along the lines of the first approach, which would probably be more difficult
for me. I've written lot's of C code which I link into a scm and now guile
repl, but this is the second approach. I have written some dynamically loaded
code in Octave as well, but I have 15+ years of C experience and no C++
experience so Octave is a bit of a problem for me.
One recent outstanding example of using guile is the snd sound editor out of
Stanford. You might look at this as an example of how really good use is made
of guile. snd and clm are really supurb pieces of software and snd (sndlib) is
probably the best showcase for guile to date.
-John