Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent parsing of curly surface syntax with keywords/parameters #3346

Closed
mlubin opened this issue Jun 10, 2013 · 3 comments
Closed

inconsistent parsing of curly surface syntax with keywords/parameters #3346

mlubin opened this issue Jun 10, 2013 · 3 comments
Assignees

Comments

@mlubin
Copy link
Member

mlubin commented Jun 10, 2013

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.

@JeffBezanson
Copy link
Sponsor Member

Related: #3143

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?

@mlubin
Copy link
Member Author

mlubin commented Jun 10, 2013

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.

@mlubin
Copy link
Member Author

mlubin commented Jun 11, 2013

Awesome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants