This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Guile & Octave (was Re: Docstring question)



	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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]