bugGNU Octave - Bugs: bug #45878, warning...

 
 

bug #45878: warning "Octave:language-extension" should only warn in user code

Submitted by:  Lachlan Andrew <lachlan>
Submitted on:  Sat 05 Sep 2015 10:14:40 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Duplicate Assigned to:  None
Originator Name:  Lachlan Open/Closed:  Closed
Release:  4.0.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 12 Sep 2015 03:22:45 PM UTC, comment #7: 

Note that this has been previously reported as bug #36743. I don't see any differences between these reports, closing this one as a duplicate.

Mike Miller <mtmiller>
Project Administrator
Tue 08 Sep 2015 05:55:58 AM UTC, comment #6: 

Thanks for the feedback.

The main issue of this bug report is:  What is the purpose of having a "language extension" warning?

(Sorry for sidetracking us on the issue of why Octave eschew's Matlab syntax.)

Carnë has said that it is not to help those of us who want to write Matlab-compatible code, but other than that, I can't see any purpose for it. Can it just be removed, to reduce code bloat?

Conversely, if others disagree with Carnë and think that it should be made useful for people writing Matlab-compatible code, then I'll happily start writing a patch to suppress spurious output.

Lachlan Andrew <lachlan>
Mon 07 Sep 2015 10:01:42 AM UTC, comment #5: 

Mike: Right. A key goal for Octave is that it allows people
the freedom to choose what works best for them. This is a
good goal, but it does not make it easy to decide what
is, on balance, best in each case.

We might think of a statement about Octave that would
be prominently displayed, and at the front of the Manual.
A title "Why Octave?" might be appropriate.

Michael Godfrey <godfrey>
Project Member
Mon 07 Sep 2015 12:25:38 AM UTC, comment #4: 

IMHO, Octave syntax is clearer and makes writing and debugging m-files easier. Incompatibility for its own sake is not a goal, we just prefer Octave's syntax. Otherwise the parser would not even implement those alternative forms.

I think an Octave-to-Matlab m-file translator would be a worthy project for someone who wants to use Octave m-files in Matlab. My own hope is that we can free users from having to run Matlab at all, but I don't want to prevent them from doing so if that's what they want to do.

Mike Miller <mtmiller>
Project Administrator
Sun 06 Sep 2015 07:28:44 AM UTC, comment #3: 

A guess: Using Octave specific syntax within the project makes it harder for The MathWorks to "steal" scripts from Octave. However, I am not sure how effective that is compared to plain GPL.

Anonymous
Sat 05 Sep 2015 11:42:26 PM UTC, comment #2: 

Thanks for the reply, Carnë.

I am happy to accept that my expectations of the warning were wrong.  In that case, what is the purpose of the warning?  If it has no purpose, then we could simplify the code by removing it from the code base :)

The issue of packages being treated as user code is a good point that I hadn't thought of.  However, it would be a simple matter of to provide a list of paths from which incompatibility warnings should be ignored when they are raised.

I really don't think that it would be that hard to implement what I am proposing, and I'd happily attempt it if I thought it would get merged upstream.

On a related note, I have often wondered why Octave .m files deliberately use a syntax incompatible with Matlab.  I can see a reason for using true enhancements, like the ++ and += operators, but what benefit is derived from replacing ~ by ! and % by # and ' by "?

If all packages were written with Matlab-compatible syntax, except where using true enhancements, then they could be used (perhaps with some minimal porting) by people who buy the base Matlab product but want to use free software for the toolboxes.

I know that Octave didn't start off as just a Matlab clone, but I think most people regard it as such now.  Is the reason for the different syntax just to argue that Octave isn't a Matlab clone?

As an example, I needed some features of  kmeans  that weren't yet implemented in Octave, and so I rewrote Octave's kmeans to provide almost all of Matlab's functionality.  Now I want a minor extension that isn't in Matlab.  As a result, I have to maintain two versions of the code -- one using #, ", ! and one using %, ', !.  That is just a waste of effort that I could use for fixing other Octave bugs.  (I'm happy to write  rows=@(x)(size(x,1))  at the start of the code; that doesn't require maintaining two sets of code.)

Thanks for the link to stack overflow.  What that gives is one down-vote from you, and three up-votes from others who share my view :)

To everyone: Are there other core Octave people who consider incompatibility-for-the-sake-of-incompatibility a benefit?

Lachlan Andrew <lachlan>
Sat 05 Sep 2015 02:11:54 PM UTC, comment #1: 

I think your expectations of what the warning did were wrong to start with. About your suggestions, do not forget about packages and other functions you may have on your system which are not actually part of Octave core and are considered as user. Also, for such warning to be a reliable thing, it would require the warning to be throw for every single thing that Octave does different. As you code, you will find that it simply does not happen, only some features actually throw warnings. Functions, or function usage, that are still missing in Matlab won't throw any warning.

The best you can do if you want to write Matlab compatible code is to either write it in Matlab or in a text editor that has separate Matlab and Octave syntax highlight (such as gedit).

Related https://stackoverflow.com/questions/12126866/octave-make-it-as-much-matlab-compatible-as-possible/12126956#12126956

Carnë Draug <carandraug>
Project Member
Sat 05 Sep 2015 10:14:40 AM UTC, original submission:  

What is the purpose of warning "Octave:language-extension"?
I am trying to write code compatible with Matlab, and though that turning this warning on would warn me when I use something not compatible with Matlab.

Instead, when I turn this warning on, it fills the screen with warnings about Octave's libraries using language extensions, but fails to tell me, for example, when I use  endif  instead of  end.

To make this warning useful, I propose that we:
1. Have a new mode for warnings.  As well as "off", "on" and "error", there could be "user", which turns the warning on in user code but off in library code.  There could also be "user-error" to raise errors if the condition occurs in user code.  I assume that fcn.is_user_code ()  can be used to test this.
2. Overhaul the places Octave:language-extension is raised, so that it reliably raises errors for code that is syntactically incompatible with Matlab.
3. Add a new warning for code syntactically compatible with Matlab, but which would cause run-time errors.

Any suggestions?

Lachlan Andrew <lachlan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lachlan (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-12 mtmiller StatusNone => Duplicate
        Open/ClosedOpen => Closed
        Dependencies- => Depends on bugs #36743

    Back to the top


    Powered by Savane 3.7