Some are unavoidable: [1 -2] vs [1 - 2] (though I think there should be a row-concatenation operator, like ; does column-concatenation. That would stop this problem).
On Wednesday, September 14, 2016 at 10:01:07 AM UTC-7, Erik Schnetter wrote: > > There was a talk at JuliaCon suggesting that parsing ambiguities are often > best resolved by throwing an error: "Fortress: Features and Lessons > Learned". > > -erik > > On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders <dpsa...@gmail.com > <javascript:>> wrote: > >> >> >> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich >> escribió: >>> >>> Ahah! That explains it. >>> >>> Is there a better way to create floating point literals that avoid this? >>> >> >> I think using 1782.0 instead of 1782. (without the 0) will solve this? >> I seem to remember there was an issue to deprecate the style without the >> 0. >> >> >>> >>> David >>> >>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson >>> wrote: >>>> >>>> >>>> >>>> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich >>>> wrote: >>>>> >>>>> Can anyone give me a quick explanation for why these statements seem >>>>> to parse differently? >>>>> >>>>> julia> 1782.^12. + 1841.^12. >>>>> >>>> >>>> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there >>>> is a parsing ambiguity here because it is not clear whether the . goes >>>> with >>>> the operator or the number. >>>> >>>> See also the discussion at >>>> >>>> https://github.com/JuliaLang/julia/issues/15731 >>>> https://github.com/JuliaLang/julia/pull/11529 >>>> >>>> for possible ways that this might be made less surprising in the future. >>>> >>> > > > -- > Erik Schnetter <schn...@gmail.com <javascript:>> > http://www.perimeterinstitute.ca/personal/eschnetter/ >
