From help-octave-request at bevo dot che dot wisc dot edu Sat Dec 9 13:14:12 2000 Subject: Re: The future of Octave From: "John W. Eaton" To: help-octave at bevo dot che dot wisc dot edu Date: Sat, 9 Dec 2000 13:13:53 -0600 On 9-Dec-2000, Manuel A. Camacho Q. 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 merits. If I attach Octave to Guile, I will almost certainly jettison almost all of the Matlab compatibility gunk so that I can simplify the translator. 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. jwe ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------