RE: Octave and Guile?

[Daschbach, John L]

Adding Guile to Octave could be a great move!

For me, octave is one of the cornerstones of my computing environment on my
Unix, Linux, and used to be OS/2 boxes.  One small example of how great it is
that I rarely write stand alone ODE codes anymore, but simply use the dynamic
loading feature in octave to get equal execution speed and all of the simplicity
of calling lsode from octave.

Octave is lacking in what I would call 'dynamic scripting' and string handling
(as well as other areas like more powerful graphics).    An example would be
that I have not found a simple way to write scripts which massage arbitrary data
and then plot it with the file names while not filling memory with data and
requiring lots of kludges and effort to get it all to work.

For this type of use, of which I have many, I use Perl scripts, called from
'system' commands in octave.  These often write .m files, which are in turn
executed by the calling script.  Overall, however the system, in my hands at
least, requires kludges to get around limitations in octave (for instance I'm
often tripped up by the lack of quoting in octave, although you can often
sprintf() a dynamic command prior to an eval.)

Thus, a 'merger' with guile would seem ideal.  I know scheme and lisp pretty
well, but have not yet spent much time with python.    Let me interject a few
thoughts on this possible merger.

1.)  In my experience, the Guile community is mostly concerned with Guile for
the sake of hacking on Guile.  It's a terribly different beast than Python or
Perl, where the authors primary aim is to develop a tool that people will use.
This approach has meant that things vital to end users (developers of other
software who wish to use Guile) have not been seriously addressed.  These
include documentation and stability of the interfaces (e.g. module system).
These appear to finally be getting closer to resolution, but until Guile has
solid documentation, a stable module system (with complete C interface), and a
complete gh_ interface, it would be risky to spend too much effort merging
Octave with Guile.

2.)  Why rewrite the interpreter in guile?  At least to start it would seem
better to just add the ability to evaluate scheme code in octave.  Although I
haven't read through the octave interpreter code, what might be good is to write
a modified guile interpreter that would evaluate all symbols in a scheme
expression but rather than throwing and error on unresolved symbols it would
take the resultant expression and evaluate it in the Octave interpreter.   With
time one could have Guile bindings for all of Octave's built-in functions, but
this way would allow Octave and scheme to be mixed in what I think would be a
natural way.

3.)  It is very easy to add scheme bindings to C functions in Guile.  This is
the primary reason I use it.  Python appears to require more work, but I could
be wrong.

4.)  Adding Guile to an established top-tier free software project like Octave
would be good for Guile, and it could be good for Octave.  Octave with Guile and
Goops has the potential to be  better than IDL (it will still need graphics!).  

I'd be very interested in this project if you decide to move ahead with it.

-John

John Daschbach
Senior Research Scientist
Environmental Molecular Sciences Lab
Pacific Northwest National Lab