Julia: Package breaks 0n 0.5 with a " invalid iteration specification"

[joa-quim]

Hi,

This is the GMT package that works fine with 0.4 and used to work too with a some months old 0.5dev, but now it errors on loading with

using GMT
... (deprecation messages)
WARNING: Base.UTF8String is deprecated, use String instead.
  likely near C:\j\.julia\v0.5\GMT\src\gmt_main.jl:57
ERROR: LoadError: LoadError: syntax: invalid iteration specification
 in include_from_node1(::String) at .\loading.jl:426 (repeats 2 times)
 in eval(::Module, ::Any) at .\boot.jl:234
 in require(::Symbol) at .\loading.jl:357
while loading C:\j\.julia\v0.5\GMT\src\gmt_main.jl, in expression starting on line 149
while loading C:\j\.julia\v0.5\GMT\src\GMT.jl, in expression starting on line 49

The offending code is

    XX = Array(GMT_RESOURCE, 1, n_items)
    for (k = 1:n_items)
        XX[k] = unsafe_load(X, k) 
    end

Julia version (nightly)

Version 0.5.0-rc0+4 (2016-07-27 09:20 UTC)
Commit 347057b (1 day old master)
x86_64-w64-mingw32

[stevengj]

It should be for k = 1:n_items. This was always the recommended style, but you are right that the parentheses were accepted under 0.4 but are rejected under 0.5.

@JeffBezanson, do you know what PR changed this behavior? It should be listed under "breaking changes" in the NEWS in any case.

[joa-quim]

I resisted years to Matlab trying to convince me to drop the parentheses. Call it old fashion but I like wrapping fors and ifs with parentheses.

What is the need to do such a needless breaking compatibility?

[stevengj]

The parentheses are C syntax. It's usually a bad idea to force the syntax from one language on another. When in Rome....

[JeffBezanson]

Changed by 8d76566d, but this aspect of the change was not intentional.

[StefanKarpinski]

I feel fairly strongly that the iterator part of a for loop should not be allowed to be parenthesized. The implicit theory behind allowing that is that the k = 1:n part of for k = 1:n is just an expression, which it isn't – it's part of the for syntax. For if statements it's a different story – the condition is just an expression so you can parenthesize it or not as you want.

[joa-quim]

And I feel sad that an ages old principle of "use parentheses freely to increase readability" has been dropped in favor of a ... I don't know what.

[Keno]

While I don't have strong feelings one way or another, I agree with Stefan that this situation is different from allowing parentheses around expressions. It is however the same as a binding in let, so it needs to be consistent with:

julia> let (k = 1)
       k
       end
1

[JeffBezanson]

an ages old principle of "use parentheses freely to increase readability"

Not in Lisp, one of the oldest programming languages :)

[JeffBezanson]

I also don't have strong feelings about this, but I will emphasize again that this was not a deliberate decision, so it's a bit overwrought to talk of dropping age-old principles or whatnot.

[tkelman]

We usually do try to go through deprecation periods for as many of these things as we can, when they are intentional decisions (like f (x) for example)

[joa-quim]

"Not in Lisp, one of the oldest programming languages :)"

And who said Lisp is readable anyway? :)

Sorry if it sound a bit hash and yes I understand that it was unintentional but from Stephan's reply it's pretty much looks like that it's here to stay.

[tkelman]

If we can change it from an error to a deprecation (or maybe allow it to continue to work?) then I think we should.

[tkelman]

Jeff, can this be fixed or turned into a deprecation warning, or should it be added to NEWS as an accidental breaking change?

[StefanKarpinski]

There is no ancient principle of "stick parens wherever you like, it will mean the same thing". What there was _and still is_ is the fact that parenthesizing a _complete expression_ does not change it's meaning. The iteration part of a for loop is not an expression, which was precisely my point.

We should:

• Either:
  
  
  
  1. Add a deprecation warning or clearer error message for this syntax change, and
  
  
  2. Also deprecate / error for parens in let, global, local, etc.
  
  
• Or:
  
  
  
  1. Make optional parens an official part of the syntax for these constructs, and
  
  
  2. Support them in for, let, global, local, etc. consistently.
  
  

I'm in favor of the former option – we should have fewer pointless syntax variations not more.

[JeffBezanson]

I'd be happy to add a usual deprecation for this.

[tkelman]

Also deprecate / error for parens in let, global, local, etc.

We should probably revisit these later and make them consistent too.