Julia: Bug parsing one-liner method with return type + where clause

[felipenoris]

This looks valid syntax but is not accepted.

julia> is_array(::T) :: Bool where {T<:AbstractArray} = true
ERROR: UndefVarError: T not defined
Stacktrace:
 [1] top-level scope at none:0

Using the same syntax, but with function keyword is accepted.

julia> function is_array(::T) :: Bool where {T<:AbstractArray}
           return true
       end
is_array (generic function with 1 method)

Removing the return type is also accepted.

julia> is_array_(::T) where {T<:AbstractArray} = true
is_array_ (generic function with 1 method)

Somewhat related issues: https://github.com/JuliaLang/julia/issues/31378, https://github.com/JuliaLang/julia/issues/31542

[JeffBezanson]

This is a difficult parser corner case. I've wrestled with it, but there is no straightforward solution. The problem is that generally the right way to parse f(x) :: A where B is as f(x) :: (A where B) because where makes types and the right side of :: has to be a type. For 1-line function definitions only though, we want (f(x) :: A) where B, but we don't know it's a function definition until we see the following =, and by then it's too late. So you need to write function (which I think is more readable for such elaborate definitions anyway), or parenthesize the f(x) :: A part.

[JeffBezanson]

Duplicate of #21847

[o314]

Sorry for the duplicate,

• may be shall we augment the lookahead?
• or consider a function is more often a type than an instance.
  
  
  
  • it is fully determined when all types are concrete and its body is fixed. quite rare
  
  
  • not an approach pushed by type theorist but well suited for set theory, model theory.
  
  
  • i can figure the number of lines of code it will impact compared to adding ( and )
  
  

Will get used to parenthesis for next upcoming years

[StefanKarpinski]

Despite the downvotes, https://github.com/JuliaLang/julia/issues/21847#issuecomment-320717445 is looking like it would have been a good call.

[o314]

Despite the downvotes, #21847 (comment) is looking like it would have been a good call.

I don"t think so. Julia is math very oriented (math everywhere?). So f(x) = ... should be a first class citizen. It is well known, accepted, short, easy to write, easy to read.
Too many qualities to be dropped.

There are certainly difficulties around hard precedence in type land with where, return etc. ; not as well battle field tested as arithmetics ops.

Parser, lowerer, runtime, interpreter are hard to read there, very monolithic, with bad code quality metrics. In the long run, there is place for improvement in those parts. Thing like this will become simpler to fix afterward.

[StefanKarpinski]

Are you volunteering to help reimplement the parser, lowering passes and interpreter? Yay!

[o314]

Some parts, yes ! We'll talk about it during the next 2-3 years i guess :)
This week, i will have finished to refactor / align macrotools with Core.IR
Let's call it a beginning.

[o314]

Good laugh.
By the way there are some simple fixes that could come quickly IMO

f(x::U,y::V) where {U,V} = (;)                              # standard form
f(x::U,y::V) where U where V = (;)                          # should warn @ julia
f(x::U,y::V,z::W) where {U,V} where W = (;)                 # should error @ julia