Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?
Slava
···
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I don't think it would be a very big parser change to invert the
relationship. Maybe I'll try it out and put up another PR.
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that
evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
···
On the other hand, noticed the header comment says:
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
Although I would also ask: why is CaptureListExpr a *parent* of
ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be
one and the same AST node. I think right now it’s just a property of how
the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev < >> swift-dev@swift.org> wrote:
I don't think it would be a very big parser change to invert the relationship. Maybe I'll try it out and put up another PR.
Unless you think there’s something to be gained, I’m not sure it’s worth it…
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
This makes sense, but as I understand it, evaluating the closure itself has no side-effects so this is irrelevant.
Slava
···
On Feb 7, 2017, at 9:18 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On the other hand, noticed the header comment says:
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I don't think it would be a very big parser change to invert the relationship. Maybe I'll try it out and put up another PR.
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
I think the original representation just made the captures part of the ClosureExpr, and IIRC Chris changed it to this intentionally. I don't remember why; maybe it was causing problems for some tooling that wanted to walk the expression tree and find uses of the variable? It's certainly kindof weird for IRGen.
John.
···
On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org> wrote:
On the other hand, noticed the header comment says:
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I don't think it would be a very big parser change to invert the
relationship. Maybe I'll try it out and put up another PR.
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that
evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
If so, why function body is NOT a child of, so to say, ParamListExpr?
That said, inverting the relationship means that every ClosureExpr has the
pointer to the capture list. Maybe we can use TrailingObjects for that, but
I'm not sure it's worth it.
···
2017-02-08 14:18 GMT+09:00 Jacob Bandes-Storch via swift-dev < swift-dev@swift.org>:
On the other hand, noticed the header comment says:
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com> >> wrote:
Although I would also ask: why is CaptureListExpr a *parent* of
ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be
one and the same AST node. I think right now it’s just a property of how
the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev < >>> swift-dev@swift.org> wrote:
Unless you think there’s something to be gained, I’m not sure it’s worth
it…
I was going for idiot-proof-ness of the AST types. I'd never heard of
CaptureListExpr before and would've just assumed it was part of
ClosureExpr. But it looks like the change was pretty intentional. (Maybe
someone can share what rdar://19146761 was?)
···
On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com> wrote:
On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev < > swift-dev@swift.org> wrote:
I don't think it would be a very big parser change to invert the
relationship. Maybe I'll try it out and put up another PR.
On the other hand, noticed the header comment says:
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that
evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
I think the original representation just made the captures part of the
ClosureExpr, and IIRC Chris changed it to this intentionally. I don't
remember why; maybe it was causing problems for some tooling that wanted to
walk the expression tree and find uses of the variable? It's certainly
kindof weird for IRGen.
John.
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com> >> wrote:
Although I would also ask: why is CaptureListExpr a *parent* of
ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be
one and the same AST node. I think right now it’s just a property of how
the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev < >>> swift-dev@swift.org> wrote:
> Unless you think there’s something to be gained, I’m not sure it’s worth it…
I was going for idiot-proof-ness of the AST types. I'd never heard of CaptureListExpr before and would've just assumed it was part of ClosureExpr. But it looks like the change was pretty intentional. (Maybe someone can share what rdar://19146761 was?)
"This crashes the compiler, we’re not setting up declcontext’s right:
func f(a : () -> ()) {}
class C {
var i = 42
func g() {
f({ [myI = {i}] in () })
}
}"
···
On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I don't think it would be a very big parser change to invert the relationship. Maybe I'll try it out and put up another PR.
On the other hand, noticed the header comment says:
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
I think the original representation just made the captures part of the ClosureExpr, and IIRC Chris changed it to this intentionally. I don't remember why; maybe it was causing problems for some tooling that wanted to walk the expression tree and find uses of the variable? It's certainly kindof weird for IRGen.
John.
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Unless you think there’s something to be gained, I’m not sure it’s worth it…
I was going for idiot-proof-ness of the AST types. I'd never heard of CaptureListExpr before and would've just assumed it was part of ClosureExpr. But it looks like the change was pretty intentional. (Maybe someone can share what rdar://19146761 <rdar://19146761> was?)
"This crashes the compiler, we’re not setting up declcontext’s right:
func f(a : () -> ()) {}
class C {
var i = 42
func g() {
f({ [myI = {i}] in () })
}
}"
Well that certainly doesn't seem like a good enough reason to complicate the expression.
...are we really emitting this as a let-binding in the outer function that we just capture normally? Er, alright, I guess it works.
John.
···
On Feb 8, 2017, at 12:33 AM, Slava Pestov <spestov@apple.com> wrote:
On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I don't think it would be a very big parser change to invert the relationship. Maybe I'll try it out and put up another PR.
On the other hand, noticed the header comment says:
/// ...Because the capture list is evaluated outside of the closure, this
/// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates
/// the variable bindings from the capture list, then evaluates the
/// subexpression (the closure itself) and returns the result.
I think the original representation just made the captures part of the ClosureExpr, and IIRC Chris changed it to this intentionally. I don't remember why; maybe it was causing problems for some tooling that wanted to walk the expression tree and find uses of the variable? It's certainly kindof weird for IRGen.
John.
On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and not a child?
I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?
Slava
Jacob
On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
