JuliaLang / JuliaSyntax.jl

The Julia compiler frontend
Other
266 stars 32 forks source link

Allow typevars in `do` expressions #437

Open sgaure opened 3 weeks ago

sgaure commented 3 weeks ago

There are several ways to create functions in julia. One of them is the do syntax. You can't dispatch on do functions, but now and then the need comes up to capture the types of variables. Although this is easy with typeof inside the function body, it turns out to be quite easy to enable the use of where clauses in the do syntax. This would make a do function similar to the other function definitions.

The reason it's easy is that such expressions are already being parsed, but a minor detail prevents it from being accepted as a valid expression:

julia-1.10.4> Meta.show_sexpr(:(f() do (x::T) where {T}; T(x) end))
(:do, (:call, :f), (:->, (:tuple, (:where, (:(::), :x, :T), :T)), (:block,
      :(#= REPL[1]:1 =#),
      (:call, :T, :x)
    )))

The where clause becomes encapsulated in a tuple. The reason is that after the parser sees do, it looks for a comma separated list. After the list is parsed, i.e. on ; or linefeed, the list is encapsulated in a tuple. This means that the where clause becomes an argument to the function, which fails as a syntax error. By modifying the parsing of do expressions to avoid inserting tuple if the newly parsed list is a where, the parse result becomes:

julia-this-PR> Meta.show_sexpr(:(f() do (x::T) where {T}; T(x) end))
(:do, (:call, :f), (:->, (:where, (:(::), :x, :T), :T), (:block,
      :(#= REPL[1]:1 =#),
      (:call, :T, :x)
    )))

This is a valid :-> expression, just like an anonymous function definition ((x::T) where T) -> T(x) currently is.

The PR is a one-line change to parser.jl, isolated to parsing what follows do. It does not enable any new or very useful functionality, it merely will make functions defined in do quite similar to other function definitions.

I don't think this change will break anything, as the construction currently results in a ERROR: syntax: ... failure.

LilithHafner commented 3 weeks ago

I think it is best for proposed syntax changes to start as or have an associated issue in the JuilaLang/julia repo for viability.