It is so nice to program in a sane language!

[recri]

Oh, that one has a bigger sibling:

julia> f = 2; f1 = 2; 2f+2f1
400.0f0

julia> 2f + 2f1
24.0f0

[Oscar_Smith]

That might just be the most horrible thing I’ve ever seen.

[dpsanders]

I’m talking about the case where n is a number, e.g.

julia> v = zeros(Int, 5);

julia> n = length(v)
5

julia> for i in n
           v[i] = i
       end

julia> v
5-element Array{Int64,1}:
 0
 0
 0
 0
 5

julia> for i in 1:n
           v[i] = i
       end

julia> v
5-element Array{Int64,1}:
 1
 2
 3
 4
 5

It’s too easy to write the former when you mean the latter, due to the fact that a number is iterable.

[Mason]

@dpsanders

I’m talking about the case where n is a number

Yes I’m aware. I occasionally find it useful.

[Raf]

You mean for generic code where n could also be an array?

This is my most common typo bug. I also wish it was an error…

[Tamas_Papp]

I don’t think you can catch this at the syntax level, since n might as well be an iterable.

The fundamental problem is that numbers are iterable. That would have to be fixed so that this can just error.

[laborg]

Just curious about others:

If you could, would you remove Numeric Literal Coefficients in Julia 2.0?

• Yes
• No
• I don’t care

[peterkovesi]

One thing that I am sure catches out many new users are the ambiguities caused by the use of white space in parsing matrices and how these ambiguities also splatter into the parsing of vectors (but not tuples).

julia> v = [ 1 - 2, 3 + 4 ]
2-element Array{Int64,1}:
 -1
  7

julia> m = [ 1 - 2  3 + 4 ]
1×2 Array{Int64,2}:
 -1  7

julia> m = [ 1 - 2  3 +4 ]
1×3 Array{Int64,2}:
 -1  3  4

julia> v = [ 1 - 2, 3 +4 ]
ERROR: syntax: missing separator in array expression

julia> v = [ 1 -2, 3 + 4 ]
ERROR: syntax: unexpected comma in matrix expression

julia> t = ( 1 -2, 3 + 4 )
(-1, 7)

I really hope something like this proposal in #7128 makes it into Julia 2.0

[Syx_Pek]

I actually think the current system is fine, just requires a little effort to get used to. I understand it maybe a little tricky initially.

Perhaps the pain of all these is to encourage people to use loop comprehensions instead.

[anon92994695]

Fun One Liners

I think I’ll just continue to define Tau myself rather then import this package. Maybe there’s some elaborate argument why it should be “tau ~ 2pi” but for my uses, it’s just 2pi. tau = 2pi Cool to know about mod2pi. Didn’t know it was in the base library, because I had no idea there was a name for this function, the code for it is well, interesting: https://github.com/JuliaLang/julia/blob/c6da87ff4bc7a855e217856757ad3413cf6d1f79/base/math.jl#L801-L987 Guess this is why I’d never call myself …

The discussion of Tau has arrived numerous times on here!

There is a package for it GitHub - JuliaMath/Tau.jl: A Julia module providing the definition of the circle constant Tau (2π)

[StefanKarpinski]

Rather than removing numeric literal coefficients, I might prefer the more radical move of changing the engineering syntax for floating point literals to something that (a) doesn’t clash with numeric literal coefficients and (b) is more extensible to different floating point sizes. Currently we have:

• 1e2 — Float64 literal
• 1E2 — means the same thing
• 1f2 — Float16 literal
• 1F2 – nope, that is NOT a float literal syntax
• no syntax for Float16 literals
• no syntax for Float128 literals (and we don’t have those… yet)

[StefanKarpinski]

Space-sensitive parsing is a real pain. Unfortunately, it also applies to macro calls, so even if we got rid of it for array concatenation, we’d still have it there.

[simeonschaub]

Could you elaborate a bit on how such a new syntax could look like? I find the current one quiet convenient and can’t really think of any syntax that’s neither taken already nor awkward to write.

[non-Jedi]

Fwiw, there’s an extensive discussion of this point (from 2014-2017) on the issue tracker.

[tamasgal]

I suggest to rename this thread to Julia: WAT!

[Tamas_Papp]

Thanks, I am aware of that, but also that it is unlikely to be changed in the foreseeable future, so I was just venting

[StefanKarpinski]

No idea

[Per]

I would like it if 1.0*10^30 were parsed as a floating point literal (instead of evaluating to 5.077e18 due to integer overflow).

[Tamas_Papp]

How would you suggest the above is parsed instead? Why not just use 1e30?

I would, instead, prefer if in general

f(literal, b, c...)

and

let a = literal
    f(a, b, c...)
end

were indistinguishable everywhere and the parser refrained from clever tricks without being asked explicitly.

That is already violated with literal integer powers (as pointed out above). When that was introduced I thought it was an especially neat trick, now I don’t think it was worth the confusion.

[Per]

@Tamas_Papp

How would you suggest the above is parsed instead?

My parsing rule would be that [literal float] * [literal integer] ^ [literal integer] would evaluate in arbitrary precision, and then yield a literal Float64 if the result would fit, and a literal BigFloat otherwise.

Yes, this would be confusing sometimes, but so is 1.0*10^30 ≈ 5.07694427030e18.

Now that I think about it, maybe [literal integer] ^ [literal integer] should always be evaluated at parse time, and yield Int128 or BigInt as necessary, just as integer literals with many digits do.

(Then you’d have to write e.g. 2^127 % Int64 if you wanted the current behavior, which I think is fair, because that is a very confusing way to write 0.)