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

produce only one Expr type from A <: B expressions #9503

Closed
stevengj opened this issue Dec 30, 2014 · 3 comments
Closed

produce only one Expr type from A <: B expressions #9503

stevengj opened this issue Dec 30, 2014 · 3 comments
Labels
breaking This change will break code parser Language parsing and surface syntax
Milestone

Comments

@stevengj
Copy link
Member

As discussed in #9474, the parsing of A <: B is currently somewhat inconsistent, and this makes metaprogamming a bit harder than necessary:

julia> dump(:(A <: B))
Expr 
  head: Symbol comparison
  args: Array(Any,(3,))
    1: Symbol A
    2: Symbol <:
    3: Symbol B
  typ: Any

julia> dump(:(type A <: B; end))
Expr 
  head: Symbol type
  args: Array(Any,(3,))
    1: Bool true
    2: Expr 
      head: Symbol <:
      args: Array(Any,(2,))
        1: Symbol A
        2: Symbol B
      typ: Any
    3: Expr 
      head: Symbol block
      args: Array(Any,(0,))
      typ: Any
  typ: Any

Perhaps A <: B should be parsed as Expr(:(<:), :A, :B) in all cases. cc: @yuyichao

@JeffBezanson
Copy link
Member

Yes, I definitely agree. Since <: is in fact a comparison operator, and one can write A <: B <: C, we should probably always parse it as a comparison. I really don't recall how it got the way it is now.

@vtjnash vtjnash added bug Indicates an unexpected problem or unintended behavior feature labels Dec 31, 2014
@JeffBezanson JeffBezanson added breaking This change will break code and removed bug Indicates an unexpected problem or unintended behavior feature labels Jan 2, 2015
@jakebolewski
Copy link
Member

Was it done this way to make it easier to apply pattern-lambda to the subtype expression?

jakebolewski added a commit that referenced this issue Jan 3, 2015
Should fix #9503

This is a backwards incompatible change, note that before
```julia
type A <: B
end
```

would be parsed as:
```julia
Expr(:type, true, Expr(:(<:), :A, :B), Expr(:block,))
```

now it is parsed as
```julia
Expr(:type, true, Expr(:comparison, :A, :(<:), :B), Expr(:block,))
```

chained subtype comparisons for type/immutable are still disallowed
```julia
type A <: B <: C
end
```
@JeffBezanson
Copy link
Member

Started working on fixing this, which in the process revealed what I think was the cause. The <: in type declarations is special syntax, and not a call to <:, so it should not have hygiene applied to it. I think the original goal was to make it easier to distinguish calls from syntax decoration.

So we could go with SGJ's suggestion of always parsing it as Expr(:(<:), ...). That would push the problem to handling comparisons A <: B <: C, which are quite uncommon.

@JeffBezanson JeffBezanson added the parser Language parsing and surface syntax label Mar 16, 2015
@jakebolewski jakebolewski added this to the 0.5.0 milestone Sep 11, 2015
JeffBezanson added a commit that referenced this issue Mar 18, 2016
fix #9503 plus another proposal on comparison and iteration syntax
dfdx pushed a commit to dfdx/julia that referenced this issue Mar 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code parser Language parsing and surface syntax
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants