octave-maintainers
[Top][All Lists]
Advanced

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

A more comprehensive braindead mode?


From: John W. Eaton
Subject: A more comprehensive braindead mode?
Date: Thu, 5 Jan 2012 15:05:27 -0500

On  4-Jan-2012, Jordi GutiƩrrez Hermoso wrote:

| Re bug #35236:
| 
|     https://savannah.gnu.org/bugs/?35236
| 
| I was thinking today... there's been more than one instance in recent
| memory where we have to go chasing after some weird Matlab behaviour.
| I always feel a little resentful whenever we have to make Octave
| stupider because Matlab is.
| 
| Why not have a flag for all of this (pardon my candid language) crap?
| We already have some of it with --braindead or --traditional flags.
| Can't we keep using that flag to implement more weird Matlab behaviour
| and use it consistently?
| 
| We could even conceivably have a --matlab-me-harder or --pedantic flag
| that does things like error out when you index a temporary or error
| out when you attempt to define a function outside of a function file.
| 
| For all the people for whom the point of Octave is "Matlab without a
| price tag", this would be useful. It would also make me a little
| happier if I had to type --braindead to enable it (everyone else can
| type --traditional, if they prefer).

I'm not fundamentally opposed to this idea, but I have some questions
about how it would be done.

What do we do about the core Octave .m files?  Do we parse them as is,
or do we have to translate them so that Octave can read them in the
new "strict Matlab mode.

In the new mdoe, do we provide only those functions that are available
in core Matlab?  If so, what do we do about core functions in Octave
that rely on extra functions not provided by Matlab?  Do we rewrite
all core Octave functions that are also core Matlab functions so that only use
functions that are part of Matlab?

What do we do about features like unwind_protect?  Can those features
be used in core Octave functions?  If so, then the list of keywords
accepted by the parser must change depending on whether core Octave
functions or user code is being parsed.

How far do you want to take compatibility?  For example, should the
internals be rewritten completely so that complex array values are
stored in separate real and imaginary arrays instead of interleaved in
a single array?

jwe


reply via email to

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