Allow macrocall as function sig

[Keno]

@KristofferC requested that function @main(args) end should work. This is currently a parse error. This PR makes it work as expected by allowing macrocall as a valid signature in function (needs to exapand to a call expr). Note that this is only the flisp changes. If this PR is accepted, an equivalent change would need to be made in JuliaSyntax.

[JeffBezanson]

I think this makes sense. A macro call is a very similar form to a call so it fits smoothly, and you might as well be able to generate a function signature with a macro.

[JeffBezanson]

This is the only tricky bit --- do we allow function @mac(x, y)::T (or with where) or does the macro generate the entire signature? Probably the latter (as you have it) but it made me stop and think.

[Keno]

I think we can allow both

[topolarity]

We already have that @mac(x, y)::T is allowed in call position and the ::T is not passed to the macro (unfortunately)

I guess we can allow you to return more syntax than the macro receives, but it seems a bit odd since it means you can end up generating redundant and/or conflicting type assertions.

[Keno]

I don't think a redundant expansion, you can always do the same directly without going through the parser. Needs to be some kind of lowering error or be given semantics. But that's independent of whether it's a legal parse or not.

[topolarity]

I just mean that the macro can't handle the case that it wants to insert a type assertion when one is already present - the obvious way to do that would have been to pass that syntax to the macro but I don't think we can do that

Unless I'm missing something?

[Keno]

Seems like people like the change, so I've addressed @JeffBezanson 's review comment and put up the same change in JuliaSyntax.jl

[c42f]

Wait what? Surely this is breaking - this syntax already means something different in the existing parser:

julia> dump(Meta.parse("function @main(args) end"))
Expr
  head: Symbol function
  args: Array{Any}((1,))
    1: Expr
      head: Symbol macrocall
      args: Array{Any}((3,))
        1: Symbol @main
        2: LineNumberNode
          line: Int64 1
          file: Symbol none
        3: Symbol args

[c42f]

Oh, I see - function @main(args) end does work in JuliaSyntax? But not in the flisp parser. Hmm!

[Keno]

Doesn't work for me in JuliaParser (without my PR):

julia> function @callmemacro(a::Int)
           return 1
       end
ERROR: ParseError:
# Error @ REPL[5]:1:10
function @callmemacro(a::Int)
#        └──────────────────┘ ── Invalid signature in function definition
Stacktrace:
 [1] top-level scope
   @ REPL:1

I guess it accidentally worked for no method body?

[c42f]

I guess it accidentally worked for no method body?

That's ... surprising and weird! But yes, correct.

[Keno]

So here's a bit of an annoyance. What does

:(function @f()() end)

parse to?
Currently it's (@f())() but with my implementation, it changes to @f(); (). Doesn't seem great. More generally, how do we decide whether or not we parse a function sig tuple? I guess the straightforward answer is "if there is one (without newline), we parse it"?

[Keno]

Actually, we already have that exact logic for the function f end case, so I can just tweak this.

[c42f]

More generally, how do we decide whether or not we parse a function sig tuple?

Oh yeaah. This was a whole big pain to get right in JuliaSyntax! Glad you could reuse the existing implementation!

(Conversely the flisp parser doesn't produce a sensible parse tree in various cases related to anon functions with function keyword etc. And the problems are fixed in lowering instead 😬 .)

[Keno]

This should be good to go from my perspective on JuliaSyntax is merged and bumped.

[Keno]

This became effective upon merging #56110, so I'll rebase and merge this to restore consistency between flisp and JuliaSyntax.

[Keno]

This became effective upon merging #56110, so I'll rebase and merge this to restore consistency between flisp and JuliaSyntax.

Actually, I'm wrong about that. It's not on the release branch. That said, I still think this is worth getting in for 1.12. @c42f preferences on doing and 0.5 release branch from JuliaSyntax master vs backporting a bunch of the fixes to the 0.4 branch?