Disallow @macroname x, y?

[simonster]

It's not immediately obvious to many people that @macroname x, y will be parsed as @macroname((x, y)) and not @macroname(x), y or @macroname(x, y). This has been a source of confusion for use of @compat (JuliaLang/Compat.jl#71, JuliaLang/Compat.jl#111, JuliaLang/Compat.jl#116, JuliaLang/Compat.jl#136, probably other places as well), but I'm not sure I've ever seen it used intentionally. In the interest of usability, we might just want to throw an error.

cc @sbromberger

[IainNZ]

Hit this today, funnily enough. We do have this construct in JuMP though:

@addConstraints mod begin
  stuff
end

Is that the same thing? We'd be happy to use the parentheses for this.

[joehuchette]

Though

@addConstraint(mod, begin
  stuff
end)

is better IMO. +1 to this.

[ScottPJones]

👍 This caused me trouble also

[simonster]

@IainNZ That's not quite the same thing. @macroname x y parses as @macroname(x, y). That seems relatively unambiguous, since x y, f(x y), etc. would not be valid expressions. What bothers me is @macroname x, y (with a comma between x and y), which passes the macro :((x, y)) as its only argument.

But since you mention it, I wonder what the rationale is/was for allowing macro calls without parens. There is certainly a lot of code that calls macros without them, but I tend to agree that things are clearer with them.

[nalimilan]

But since you mention it, I wonder what the rationale is/was for allowing macro calls without parens. There is certainly a lot of code that calls macros without them, but I tend to agree that things are clearer with them.

I think it allows for clearer code when using macros like @inbounds. It makes it closer to a built-in language keyword. When the macro applies to the whole expression (only one argument), parentheses don't add any value.

But +1 for your proposal.

[ivarne]

@simonster This is definetly two different issues.

1. Parsing of macros and tuples (require parentheses to dissambiguate).
2. Confusion caused by parentheses less macro calls for 1 and N arg macro innovocations.

I like tuples without parentheses when the meaning is clear, but this issue seems to indicate that we should require parentheses when combined with macros.

I like the possibility to have 1 argument macros without parentheses (eg @inbounds begin .... end), but I haven't yet managed to internalize the parsing rules for multiple arguments separated by spaces, so I need to try and see what works each time. If we remove n>1 arg macrocalls without parentheses, that would make Julia a simpler language to learn and fully master.

[carlobaldassi]

If we remove n>1 arg macrocalls without parentheses

-10¹⁰ for this, please don't. It's useful feature when using macros to create DSLs (like done by JuMP, ArgParse, etc.); differentiating between one and more args is inconsistent and annoying.

(I have no problems in removing the parenthesis-less tuples in macro arguments even though I occasionally use them, the distinction is in fact subtle.)

[rened]

same as @carlobaldassi - DSLs like FunctionalData et al require the @somemacro a b c syntax - removing this would kill off a huge appeal of Julia

[yuyichao]

I agree @macro x, y might be confusing. However, the alternative syntax would be @macro (x, y), which would be even more confusing... (since it's different from @macro(x, y))

[yuyichao]

In another word, I find both @macro x, y and @macro (x, y) are confusing at the same level and it would be too much to disallow both. (Although the first one may couse more confusing in the context of Compat)

[tkelman]

Personally I have a really hard time reading @rened's code that uses FunctionalData, when it's otherwise doing things that I would find useful. With the exception of the above begin end block syntax, most of the macro calls in code that uses JuMP use parens anyway. Much easier to visually parse when macros don't use the space-sensitive mode.

This issue's primarily about the comma-vs-tuple confusion though.

[rened]

@tkelman yeah, I know, it looks very different. have to expand the documentation and add a tutorial. DSLs are always a tradeoff - another thing to learn, but they can make certain problems drastically easier to formulate / solve. I would not dare to heavily promote a pet DSL, but it would an absolute shame to loose the ability to implement/use them.

back on topic, I believe disallowing the @macro a, b seems ok on first sight, but having macro parsing work differently for a single case is also confusing. i'd rather not have special parsing rule for this case, but i'd be ok with both.

[ScottPJones]

I don't have a problem with @foo a b c, which becomes a call to the macro foo(a,b,c), and passing a tuple to a macro, while a bit confusing because of the difference between @foo(a,b,c) and @foo (a,b,c), the real problem is the comma-less tuples, and not just in macro calls.

function foo(a,b,c)
    ....code....
    expr1,
   # comments
   # blah, blah, blah
   # blah, blah, blah
   expr2
end

The little comma above really changes everything.
If comma-less tuples weren't allowed, then the language would be a lot clearer with a lot of these edge cases.
Another example: [a, b, c] vs. [(a,b,c)] vs a,b,c and (a,b,c).
Parsing gets even more inconsistent when you consider how the syntax within [ ].
[[1,2,3],[4,5,6],[7,8,9]] gives a deprecation warning and a 9x1 array, instead of the 3x3 array
JavaScript, Python (and other languages) would return, however
[(1,2,3),(4,5,6),(7,8,9)] gives a vector with 3 length 3 tuples.