[Octave-bug-tracker] [bug #36743] Octave:language-extension warning warns about Octave's own files

[Carnë Draug]

Follow-up Comment #8, bug #36743 (project octave):

Lachlan Andrew said on comment #7:

> [...] That needs to be a separate warning (as it was in 3.8, IIRC). 

Why is that? What's the reason to place the extra syntax
"automatic-broadcasting" in a separate "bucket" than the others extra syntax?
If the reason is that you didn't saw warnings back in 3.8, that's because all
the code in packages and core that made use of it, turned off the warnings
locally. This is not acceptable. A developer should not have to disable
warnings to make use of standard language syntax.

> [...] Most of my use of Octave is for lists rather than true vectors. If I
add a 1xn to an nx1, I want either to get an n-dimensional vector, or an
error.

Why would you want an error? Does your code on Matlab relies on getting an
error to choose an alternative codepath? I can't imagine another reason where
an error would be desirable and even then, it could be argued that you should
be doing input check rather than relying on an error.

> [...] Then I get inundated with errors. Even if I didn't, it would preclude
the many useful Octave extensions, like +=, ++, (A+B)(10), which are
syntactically different and so presumably intentional. 

This confuses me. I thought the issue was all the matlab incompatible syntax. 
This sounds like you just don't want automatic broadcasting which is a whole
different issue.  And it's akin to not liking that "*" or "^" does matrix
operations because you don't do matrix operations, and so wanting a switch to
disable them.

> @Carnë, I can see a case for getting rid of the option. However, the
overhead of checking syntax is only incurred when the file is parsed -- when
it is first read in -- not every time it is executed. (Try turning the warning
on, and watch it appear only when a new code path is executed.)

The warning is only issued but that's because it checks everytime, if the user
has been warned before.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36743>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/