You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The expression tree generated for keyword arguments changes if parameters are present or not:
julia>dump(:(f{a=1}))
Expr
head: Symbol curly
args:Array(Any,(2,))
1: Symbol f
2: Expr
head: Symbol =
args:Array(Any,(2,))
1: Symbol a
2: Int64 1
typ: Any
typ: Any
julia>dump(:(f{a=1;b=2}))
Expr
head: Symbol curly
args:Array(Any,(3,))
1: Symbol f
2: Expr
head: Symbol keywords
args:Array(Any,(1,))
1: Expr
head: Symbol =
args:Array(Any,(2,))
typ: Any
typ: Any
3: Expr
head: Symbol parameters
args:Array(Any,(1,))
1: Expr
head: Symbol =
args:Array(Any,(2,))
typ: Any
typ: Any
typ: Any
This makes it more difficult to parse inside macros. I'd actually prefer to not have the keyword arguments separate in this case, because it destroys the order and makes it impossible to parse the difference between f{1,y=2} and f{y=2,1} which is important for the syntax of MathProg, where it means something entirely different from keyword arguments.
The text was updated successfully, but these errors were encountered:
The big problem here is that in some cases, calls contain assignments that are not keyword arguments. For example you can write x = (y=z) + 2, which does an assignment instead of passing a keyword argument to +. I think the only way I can resolve this is to parse keyword arguments as (kw a b) instead of (= a b). Then you would have to know to look for :kw instead of :(=), but these other problems would not be there. Does that seem ok?
MathProg's use of = was in part because the syntax was available, we use it for sum{ x[i]*y[i], i = 1:N }. I'd be happy to use in instead to avoid the conflicts with keyword arguments, if that syntax could be made parseable, i.e., sum{ x[i]*y[i], i in 1:N }. Otherwise, it's easy to look for :kw instead of :=, but it would be great if the order wasn't destroyed.
The expression tree generated for keyword arguments changes if parameters are present or not:
This makes it more difficult to parse inside macros. I'd actually prefer to not have the keyword arguments separate in this case, because it destroys the order and makes it impossible to parse the difference between
f{1,y=2}
andf{y=2,1}
which is important for the syntax of MathProg, where it means something entirely different from keyword arguments.The text was updated successfully, but these errors were encountered: