From an a to an e is just a few keys on the keyboard. And it isn’t just e:
julia> f = 2
2
julia> 3f-3
3.00000e-03
julia> 3f - 3
3
From an a to an e is just a few keys on the keyboard. And it isn’t just e:
julia> f = 2
2
julia> 3f-3
3.00000e-03
julia> 3f - 3
3
Another little inconsistency:
julia> e,E,f,F = 3,3,3,3
(3, 3, 3, 3)
julia> 3e-3, 3f-3, 3E-3, 3F-3
(0.003, 0.003f0, 0.003, 6)
'e'
is case insensitive, while 'f'
is case sensitive.
(aside: I like 2a == 2*a
, but Float32 literals can change)
Why not 2(x+2)/3a
?
This is kinda cursed ngl
Interestingly, the Discourse syntax highlighting [incorrectly] shows 3F-3
as a numeric literal, but my VSCode syntax highlighting [correctly] doesn’t.
(also, I should pick different colors in VSCode; the color of numeric literals is too close for comfort to variables.)
To be wild here, what if we did away with 2e9 notation instead? It’s not a great syntax. It’s not obvious at all and people often expect it to produce an integer. You could make 2×10^9 a literal syntax instead, which is much more obvious and could produce an integer. If we disallowed 2e9 and required 2.0e9 for the float literal and also disallowed float literal juxtaposition then there wouldn’t be any more syntax ambiguities.
Since you are a newcomer here, I should probably point you to this post: PSA: Julia is not at that stage of development anymore
I mean as a 2.0 thing, of course. But yeah, maybe too disruptive. Of course literal syntax changes are the easiest thing to automatically update. We could also have syntax changes be module-locally opt-in pre 2.0 and opt-out post 2.0.
I like this. I’d opt-in just for the peace of mind.
More times have I accidentally used it hoping to declare a large integer, than actually wanting a float.
this gives me mild pause, as I wouldn’t be able to write 0.25x
or 2.5y
, but I think it’s worth it to maintain the ability to write 1.602e-19
. Thumbs up from me, for whatever that’s worth.
I am now deceased.
Edit:
I’m not sure how difficult it’d be, but for float literal juxtaposition I wouldn’t be opposed to parentheses-wrapped float literals. Namely, 2.5y
might no longer work, but (2.5)y
could still be allowed.
Currently this works: 1.602e-19n
, but it really feels like it should be wrapped in parentheses, e.g. (1.602e-19)n
.
This is an impressive array of syntax oddities you’ve got here.
<(5)
is the function call you want and the whitespace rules allow spaces for separators in hcat
. The latter is parsed this way because <
is considered a binary operator and the ()
are ignored as a possible function call. Possibly this could be fixed, maybe. Whitespace sensitive parsing is a bit of a nightmare of special cases.:
acts as a range operator here, which has higher precedence than the >
in the if
. Nothing we can do about this I suspect.(a, b = 1, 2; a+b)
as a “frakentuple” JuliaSyntax.jl/parser.jl at eb9fd054b454b158aa17c6ebe3f9d5fd584faf47 · JuliaLang/JuliaSyntax.jl · GitHub) and it’s actually a lowering error you see here. There are tricky edge cases in how commas and semicolons inside parens are disambiguated to give tuples vs named tuples vs frankentuples vs plain old blocks. The local
works because it gobbles up the commas and makes the inside of the parens into a block not a tuple.f(x)
as (f) (x)
: the parser considers the trailing (
to be function call syntax, but it’s not allowed with whitespace before the (
JuliaSyntax
over all of General so we have some tooling for this.Int [1 2]
vs Int[1 2]
. Ie the parser is trying to parse typed_hcat
here.JuliaSyntax.jl aims to parse the vast majority of Julia syntax compatibly, with exceptions only when
So there’s various obscure and somewhat unfortunate behaviors in the reference parser which we replicate to avoid breaking things.
In the future I feel we could deprecate or change certain obscure and problematic syntax on some kind of per-project or per-module opt-in basis, eventually leading up to making it the default in Julia 2.0. If it’s opt-in, old code continues working but the tricky part is driving adoption so that there’s some mechanism to roll those changes out and shake out bugs. Hmm. Maybe we could infer syntax variant based on the Julia version range declared in the project file? Then the roll over to Julia 2.0 would just be a special case of a general system for rolling minor syntax updates.
Even if there’s a system of syntax variants, it’s important that all packages which would otherwise work together continue to work together. No splitting the ecosystem
Speaking of excess parentheses, there’s various places these are allowed and I have very mixed feelings about. An extreme example with juxtaposition
julia> (((((((6)))))))(((((((7)))))))
42
And a fun one with keyword argument syntax
julia> f(;kws...) = kws
f (generic function with 1 method)
julia> f(a=1) # ok sure
pairs(::NamedTuple) with 1 entry:
:a => 1
julia> f(((((((((a=1))))))))) # now what?
pairs(::NamedTuple) with 1 entry:
:a => 1
Good point, but for this, 2*(x+2)/3a
is just as nice. Outside parentheses it becomes weird, imo.
That’s a bit unfortunate.
Having an easy notation for this is really important, imo, and I do miss a similarly convenient notation for integers. Perhaps 2e9
could be an integer, and 2.0e9
would be the float. Pretty disruptive, though…
2.5*y
is much nicer than (2.5)y
, so the point of it is gone.
no no, as proposed above we might be required to have “excess” parentheses if we wish to have floating-point juxtaposition, in order to eliminate ambiguities.
We can construct similar in the flag-bearer for syntactical restraint, so I think the ability to have excess parens isn’t a big deal:
>>> def myfun(x):
... return x
...
>>> myfun((((((((((((((((1))))))))))))))))
1
What if we take the inverse? 3a/2(x+2)
versus 3a/(2*(x+2))
or 3a/2/(x+2)
?
That defeats the purpose of the proposal, which would make it so that 2e9
unambiguously scales a variable e9
by a constant integer 2
. Currently the mere presence of 2e9
(and 2e+9
and 2e-9
) as a numeric literal causes some pretty sketchy ambiguity.
So by the proposal:
2e9 == (2)e9 == 2(e9) == (2)(e9) == 2 * e9
2.0e9 == (2.0)10^9 == 2.0(10^9) == (2.0)(10^9) == 2.0 * 10^9
2×10^9 == (2)10^9 == 2(10^9) == (2)(10^9) == 2 * 10^9
I don’t know that it’s entirely gone though. I’d argue that (1.602e-19)n
is clearer to read than either 1.602e-19*n
or (1.602e-19)*n
. Also, you may (or may not) have positive feelings towards the syntax of constant-scaled denominators as above. I think it’s worth it to eliminate the ambiguity.
Also the rule doesn’t have to extend to macros, so Unitful.jl 9.8u"m/s^2"
could stay unchanged.
Yeah, I thought of that. But something/2(x+2)
looks ambiguous, unlike something/2x
. Even in hand-written math notation I would hesitate to use y/2(x+2), prefering instead y/(2(x+2)) or \frac{y}{2(x+2)}.
Yes, but that would be terrible, since 2e9
(or 2.0e9
) is extremely useful, even more than the juxtaposition syntax itself.
But 1.602e-19 * n
is better than either. The point of the juxtaposition syntax is aesthetic, so it really only makes sense to use it when it improves legibility. The examples provided seem to be specifically designed to diminish legibility.
You are basically trying to come up with the worst ways to abuse notation as an argument to remove it, while most use it for the opposite purpose. It think it would be really sad if we remove something that can be very helpful because it can be used in a perverse way. There are endless opportunities for writing horrible, unreadable code, I don’t see why this (very nice) syntax is particularly problematic.
A simple rule could be:
Implicit multiplication syntax looks like this:
[numeric literal][identifier OR function call]
This would only allow code like 4a, 4rand(), 4.0b, 4.0randn(4)
. No (4)a
, no 4(a)
, no arbitrary expressions after the numeric literal like 4(a + b)
.
Surprised noone suggested something Unicode yet. So here goes:
julia> ⏨(i) = i < 0 ? 10.0^i : 10^i
⏨ (generic function with 1 method)
julia> 2⏨(5)
200000
For some reason the code snippet
font displays ⏨ as ⏨
in superscript. The keyboard input description could be \tento
.
This isn’t a serious suggestion, but does reduce ambiguity.
Now, this is what I call non-obvious syntax.
julia> x=3
3
julia> a=2
2
julia> (2x + 4)/3a
1.66667e+00
julia> (2x + 4)/3*a
6.66667e+00
I think this is very clear and desirable. It’s in fact the main thing I like about this syntax.
For someone expecting the rules of operator precedence to hold, it is the opposite of desirable.
It’s the same as the difference between (2x + 4)/3a and (2x + 4)/3\cdot a, which is what makes this work so well. The behaviour of juxtaposition below the division sign is the main attraction of this syntax for me.
But the point of disallowing 2e9 is to eliminate syntax ambiguity with numeric literal juxtaposition. Giving it a different meaning doesn’t help at all, it’s just breakage with no benefit. The point would be that the integer must be written as 2×10^9
while the float must be written as 2.0e9
leaving, 2e9
as only meaning 2*e9
, thereby eliminating the exceptions to the literal juxtaposition syntax.