bugGNU Octave - Bugs: bug #36658, syntax change for initialization...

 
 

bug #36658: syntax change for initialization of global/persistent variables

Submitter:  None
Submitted:  Thu 14 Jun 2012 06:24:32 PM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  1 - Later Item Group:  Feature Request
Status:  Wont Fix Assigned to:  None
Originator Name:  Lev Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 02 Aug 2021 01:16:08 PM UTC, comment #28: 

I agree that the possible advantage of changing global/persistent initialization does not outweigh the possible pain that introducing a possibly breaking change would have.
Having two different syntax variations that do the same thing is probably more confusing than the current (cleaner) syntax. Additionally, that would add the possibility that it might clash with a future syntax extension by Matlab.
Imho, the current behavior and syntax is clear enough and a positive difference to Matlab. So, I agree that we should keep it.

The situation might be different if Matlab should decide to introduce global/persistent initializations with incompatible syntax at some point in the future.

For now, I'll close this report as won't fix.

Please, re-open if you disagree.

Markus Mützel <mmuetzel>
Group administrator
Mon 02 Aug 2021 12:36:27 PM UTC, comment #27: 

I noticed this report again because Kai changed the status to "Patch Submitted".

At this point, with our long history of new syntax and semantics causing trouble with compatibility (whether currently or in the future because of changes in Matlab) I propose that we either make no change and hope that there are no future changes to Matlab that cause trouble for Octave or we deprecate global and persistent variable initialization.

John W. Eaton <jwe>
Group administrator
Thu 04 Jun 2015 10:38:54 PM UTC, comment #26: 

I think it's up to you whether you want to include the extra information about the declaration type (global or persistent).  I would vote for making it easy and not having the type declaration, just the value as for any other variable.

Rik <rik5>
Group administrator
Thu 04 Jun 2015 09:30:03 PM UTC, comment #25: 

I suppose that if we make this change we'll also have to do the same for persistent variables.

John W. Eaton <jwe>
Group administrator
Thu 04 Jun 2015 09:28:33 PM UTC, comment #24: 

The message will only be printed when the value is initialized, correct?  So to avoid confusion, should it maybe also indicate that it is a global variable initialization?  Something like


[global initialization] a = 1


?

John W. Eaton <jwe>
Group administrator
Thu 04 Jun 2015 06:25:40 PM UTC, comment #23: 

Initializations are an Octave-only feature, so I would separate the two ideas.

Declarations are Matlab-compatible and don't involve printing anything.


global a


produces no output.

An initialization, which is a combination of a declaration and assignment, would follow Octave's rules for assignment and print something unless terminated with a semicolon.


global a = 1
=>
a =  1



Rik <rik5>
Group administrator
Thu 04 Jun 2015 05:38:32 PM UTC, comment #22: 

I suppose it could print, but what about


global a


?  That also sets a value for A (implicitly to the empty matrix) the first time it is evaluated.  But it seems weird to print anything there and Matlab users certainly won't expect it.

Maybe optionally?  I don't know.

John W. Eaton <jwe>
Group administrator
Thu 04 Jun 2015 04:19:13 AM UTC, comment #21: 

Fine.  We don't have to make a syntax change.

What about the printing/non-printing issue?  Shouldn't the following code print something because it doesn't end with a semicolon?


global a = 1



Rik <rik5>
Group administrator
Thu 04 Jun 2015 12:46:56 AM UTC, comment #20: 

Is this syntax change something we still want to pursue in a future version of Octave? This bug has been dormant for almost 3 years.

I agree with Michael and jwe, I don't think a new syntax is going to make things any clearer or less confusing, and the current behavior is clearly documented in the manual.

Mike Miller <mtmiller>
Group Member
Tue 03 Jul 2012 02:56:33 AM UTC, comment #19: 

This issue could be, actually already has been, discussed
for many years.  I very much doubt if there is anything
like a "good" solution, or even one that is in practice
much different from Octave as it is.

Any form of initiaization of global data is error prone.

While Rik's proposal has good features it seems to me that
it would end up, after lots of upset, to be subject to
the same problems as the present.

The worst feature of all this is that it tends to catch the
people who are quite expert and careful: just one forgetful
or forgotten line will do it.

So, unless we want unconditionally to issue a warning on any
global intialization saying something like "do you REALLY
want to do something this risky", we should just leave it
as it is.

Michael Godfrey <godfrey>
Group Member
Tue 03 Jul 2012 12:55:50 AM UTC, comment #18: 

Sorry about jumping on that before looking at at the patch.

I'm still not convinced that this change is needed.  Using '=' doesn't cause a conflict and it has been in use for at least 15 years.  This is the first time I can remember a complaint about this syntax.  So I think it would be good to post the NEWS entry to the maintainers list and ask for reaction there before committing this change.

Also, I count about 60 places where Octave Forge code needs to be changed.  How much other user code will this affect?  My feeling is that most people who suddenly see this warning will just be annoyed by what they see as an unnecessary change in syntax.

John W. Eaton <jwe>
Group administrator
Tue 03 Jul 2012 12:40:38 AM UTC, comment #17: 

I actually did use hyphens in the warning ID, but mistyped as I was writing up what I did.

Rik <rik5>
Group administrator
Tue 03 Jul 2012 12:38:59 AM UTC, comment #16: 

To be consistent with other warning IDs in Octave, please use hyphens instead of underscores to separate words.

John W. Eaton <jwe>
Group administrator
Tue 03 Jul 2012 12:36:11 AM UTC, comment #15: 

I've made a patch based on jwe's suggestion which implements a new syntax (':=') for variable initialization.  Try it out and see what you think.

Other changes:
1) I added a new Octave warning ID (Octave:initialization_syntax) so that the warning about using the old syntax can be suppressed.  The warning is on by default.

2) I updated NEWS with the new behavior and put in a sunset clause of 3.12 for the current initialization syntax.

3) The Texinfo documentation has been updated.  It now seems clearer to me what is intended by initialization.

4) All of the scripts in the Octave source tree have been updated to use the new syntax.

Incidentally, I kept the current syntax for assigning the default value of variables in function headers.  This seemed clearer to me since A) it is reminiscent of existing programming languages like C++ and B) it squares with my mental model of the variable being "assigned" a value which is then overriden if the user supplies something different.  We could change to use the same ':=' syntax if we want, but it does generate a lot of warnings currently.


(file #26140)

Rik <rik5>
Group administrator
Mon 02 Jul 2012 11:23:55 PM UTC, comment #14: 

Well, I haven't met with this yet.

Naively, I would expect error at the second defvar since xvar has already been defined.

Torok Levente <lev>
Mon 02 Jul 2012 11:09:08 PM UTC, comment #13: 

Emacs Lisp has defvar.  It works roughly the same way as initialization in Octave:


(defvar xvar 13)
xvar
   ==> 13
(setq xvar 42)
xvar
   ==> 42
(defvar xvar 7)
xvar
   ==> 42


so this behavior is not exactly unprecedented.

John W. Eaton <jwe>
Group administrator
Mon 02 Jul 2012 10:47:37 PM UTC, comment #12: 

I feel it to be a very much misleading and dangerous to have global a=b having no effect in certain cases. No matter if it is documented or not.

On the other hand, I cannot remember if any scripting language that has global variables with initializers. This is probably comes from that, people perceive initialization happening during compile time but not at running time.
However since scripting languages do not have "compile time", I would not expect such a functionality at all.
So I think this possibility is more confusing than offering a challenges.

How


Torok Levente <lev>
Mon 02 Jul 2012 05:30:45 PM UTC, comment #11: 

Oops, in my patch, I accidentally changed lexer_flags to Lexer_flags, so you'll need to fix that after appyling the patch.

John W. Eaton <jwe>
Group administrator
Mon 02 Jul 2012 05:28:06 PM UTC, comment #10: 

I don't think the change to the lexer and parser is difficult (see the attached preliminary patch).  If you feel strongly about it, then feel free to fix the documentation, decide whether to fix the Octave sources to use ':=' instead of '=', and decide whether to deprecate and eventually make '=' not work in the context of initialization.

Note that this change also affects default values for funtcion arguments.


(file #26138)

John W. Eaton <jwe>
Group administrator
Mon 02 Jul 2012 04:59:46 PM UTC, comment #9: 

At some point I would still like to make changes in this area.  I see the downsides, supporting side-by-side syntax for a while, but I also like the upsides.

The clarity issue is important because even when we document and tell people what something does, they still program based on their expectations and internal model.  Octave is a vector/matrix based language.  We tell people this again and again, and yet they still want to use for loops over indices.  In the end, we accommodate their internal model by putting in a JIT compiler for loops.

Right now initialization looks like assignment and documenting that they are different doesn't seem to be succeeding.

This isn't a top concern for me either, so I've lowered the priority to 1-Later, changed the Item Group to Feature Request, and changed the Summary field to reflect the discussions here.  Maybe the next time the parser really gets ripped open, say for adding classdef support, this issue can be re-visited.

Rik <rik5>
Group administrator
Mon 02 Jul 2012 03:46:59 PM UTC, comment #8: 

The current behavior is clearly documented and I don't think it is a bug.

It might help to make a change to use different syntax, but I think some people will still be confused when they write the initialization and it doesn't seem to have any effect beuause the variable they are tagging as global has already been initialized.  It's possible, but I doubt that a different syntax will solve thatt problem.

If we make a syntax change, then we have to support both operators for some period of time.  And if we do eventually eliminate the existing syntax, we are likely to annoy people who see little point to such a change.

So I don't see a lot of upside to making a change.  I'd prefer to just leave it alone.


John W. Eaton <jwe>
Group administrator
Mon 02 Jul 2012 03:29:30 PM UTC, comment #7: 

I took a look at the Matlab documentation and, as Michael has verified, they don't support initializers for global or persistent variables.  I think inititializers, particularly for persistent variables, are a good thing and Octave should have them.

Since we don't need to meet Matlab compatibility we can follow our own path.  I would argue that the confusing thing in this situation is that initialization looks just like assignment.  If the two operations appear different then I wouldn't expect that they do the same thing. 

What about one of the following symbols for initialization?


global a := 1
global a <= 1
global a @= 1


Rik <rik5>
Group administrator
Mon 02 Jul 2012 10:38:50 AM UTC, comment #6: 

Matlab:

>> version


ans =

7.9.0.529 (R2009b)

>> global g =13

??? global g =13
             |
Error: The expression to the left of the equals sign is not a valid target for an assignment.
 

>>


Michael Godfrey <godfrey>
Group Member
Mon 02 Jul 2012 06:35:55 AM UTC, comment #5: 

@Rik
Sorry, I was offline for about a week time.
As I see John have pointed out the heart of the bug. Thanks.

I don't know how matlab handles global statement but I should give priority to their solution.

If you don't see this that much important, then I'd suggest the a = 3 pattern, too, since "a = 2" case would be very misleading.

The other reason I would suggest  "a = 3" is that.
I usually collect all the interactively written commands in a text editor and run it as a script, later.
Usually, I run it many times with slight modifications and  if it has a global statement at the beginning it would cause me a trouble since the second run would have effect on the value of the variable.

@jwe
I would vote on 13.
What would make you think of 42, other than universe and everything?

Torok Levente <lev>
Fri 29 Jun 2012 07:46:03 PM UTC, comment #4: 

If you think that initialization should happen any time that a global statement appears, then what should happen when the initializer appears in a function body?  For example, given the function


function f ()
  global g = 13;
end


what should the value of g be after doing


global g = 42
f ()


?

Maybe having initializers is just bad design.  When I introduced it to Octave, I thought it would be helpful, but I realized that it could cause some confusion.

As for the printing issue, I'm not sure what my reasoning was at the time.  I probably skipped printing of the initialization expression because the simple global declaration doesn't print the current value either.

John W. Eaton <jwe>
Group administrator
Fri 29 Jun 2012 07:26:10 PM UTC, comment #3: 

What behavior is desirable?  It seems slightly more logical to me that if the variable is already global, then the scoping operator is ignored and the assignment takes place.

Sample Code:


octave:1> b = 2;
octave:2> global a = b
octave:3> a
a =  2
octave:4> b++;
octave:5> global a = b
octave:6> a
a =  2


I would vote for having a = 3 on the last line.

A second question is why the global scoping operator suppresses normal output.  Usually a line which isn't terminated with a semicolon echoes its output, but that isn't the case for global.

More Sample Code:


octave:1> x = 1
x =  1
octave:2> global y = 2



Rik <rik5>
Group administrator
Thu 28 Jun 2012 12:20:31 PM UTC, comment #2: 

If you have mulitple "global var = val" statements for the same variable, only the first to be evaluated will set the value because initialization only happens once.

John W. Eaton <jwe>
Group administrator
Thu 28 Jun 2012 10:02:26 AM UTC, comment #1: 

Hello Lev,

I could not reproduce that behaviour. Could you write a few lines of script that will reproduce that behaviour you mentioned?

Jacob Dawid <jacobdawid>
Thu 14 Jun 2012 06:24:32 PM UTC, original submission:  

Hi,
Octave interpreter accepts
global a=b
however = doesn't take effect.
I suggest to throw error according to the misleading and accepted syntax.

Cheers,
Lev

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #26140:  init_syntax.patch added by rik5 (39KiB - application/x-download)
file #26138:  diffs.txt added by jwe (2KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by lev (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-02 mmuetzel StatusPatch Submitted Wont Fix
        Open/ClosedOpen Closed
    2021-08-02 siko1056 StatusNone Patch Submitted
    2015-06-04 mtmiller Assigned tojacobdawid None
        Release3.6.1 dev
        Operating SystemGNU/Linux Any
    2012-07-03 rik5 Attached File- Added init_syntax.patch, #26140
    2012-07-02 jwe Attached File- Added diffs.txt, #26138
    2012-07-02 rik5 Severity3 - Normal 1 - Wish
        Priority5 - Normal 1 - Later
        Item GroupInaccurate Result Feature Request
        Summaryacceptance of &quot;global a = b&quot; syntax change for initialization of global/persistent variables
    2012-06-28 jacobdawid Assigned toNone jacobdawid

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code