Splitting expressions inside of array syntax is space sensitive as well:
julia> [1 + 2]
1-element Array{Int64,1}:
3
julia> [1 +2]
1x2 Array{Int64,2}:
1 2
Of course this bothers me too, but it's another example of
space-sensitivity..
On Mon, Jan 5, 2015 at 5:42 PM, Hans W Borchers <hwborch...@gmail.com>
wrote:
> Style guides are not syntax rules. Every body writes n+1 at times.
> Is there any other place in Julia where putting spaces (or not putting
> spaces)
> around arithmetical operators makes a difference?
> Would this be allowed by the general Julia philosophy?
> Will it not lead to errors very difficult to track down?
>
>
>
> On Monday, January 5, 2015 9:33:41 PM UTC+1, Jeff Waller wrote:
>>
>> The cause for this thread is mainly a lexical analyzer bug for hex
>> notation. Except for the error in #9617, I'm fine with the current behavior
>> and syntax even with the semi e-ambiguity if you want the scientific
>> notation literal, use no spaces. This is only ambiguous because Julia
>> permits a number literal N to proceed an identifier I as a shortcut for
>> N*I, which is different than many languages and part of Julia's charm. I'd
>> be sorry to see it go.
>>
>> [0-9]+(.[0-9]+)?e(+|-)?[0-9]+ <---- scientific notation literal
>>
>> 2e+1 is 2x10^1
>> 2e + 1 is 2*e + 1
>> 2e+ 1 is a syntax error because to the lexical analyzer 2e+ is an
>> error without at least 1 trailing digit (no spaces)
>>
>> typing 2e+1 (without the space) and expecting it to mean 2*e + 1 is way
>> over emphasizing the need to not type a space. All of the other language
>> style guides are consistent about this being bad style.
>>
>> Finally consider this
>>
>> *julia> *
>> *2e-1e**0.5436563656918091*
>>
>> This is parsed as (2*10^-1)e = .2e which I assert is the right thing to
>> do.
>>
>
