[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The future of Octave

From: John W. Eaton
Subject: Re: The future of Octave
Date: Sat, 9 Dec 2000 13:13:53 -0600

On  9-Dec-2000, Manuel A. Camacho Q. <address@hidden> wrote:

| Yep. I think that's the point. Instead of making Octave "ML compatible",
| we can better think of a file translator, made with an scripting tool to
| convert .m files to Octave files.

If you want to head down that path, then I think it makes more sense
to use a translator to convert Matlab code to a more full-featured
scripting language.  A similar translator would be written for Octave
(or whatever the new environment that does not attempt Matlab
compatibility is called).  Both translators would share the same
underlying library and interpreter, so both could be used together,
along with any code written for the underlying scripting language.

If you agree with this approach, at least in principle, then you will
probably want to have your favorite scripting language at the core.
People will probably argue that one language is more popular or has
more add-ons than another, so it should be used.  There will be Python
and Perl advocates, and people who just like Tcl, or Java.  But my
choice would probably be something like Scheme, which is powerful, and
should be relatively easy to use as a target for translation.

Using such an approach, you don't have to write Scheme code if you
don't like it, you can write Octave code and pass it through the
translator, and people who want to use the strict Matlab translator
can still have access to your code.  Likewise, people who use Octave
have access to all the Matlab code, via the translator.  And both have
access to any other modules written for the Scheme interpreter.

I passed this idea by the Guile maintainers and users several months
ago, and they were enthusiastic about it.  I'm not sure it is the path
I will eventually choose, but it is interesting to me.  In any case,
arguments about the popularity of the underlying scripting language
are not likely to sway me.  I am much more interested in the technical

If I attach Octave to Guile, I will almost certainly jettison almost
all of the Matlab compatibility gunk so that I can simplify the

I have no plans to write or maintain a Matlab translator myself.  That
task will have to be left to someone who is interested.  And, if you
are going to tackle a project like this, I would recommend trying for
strict bug-for-bug compatibility, so that you don't have to worry
about your innovations clashing with future Matlab features.


Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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