Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
We already have begin-with-definitions. Would there be a great penalty to simply wrap every body-like sequence of expressions and definitions with begin-with-definitions? The latter even allows more freedom than (let () def ... expr ...), for it allows (begin-with-definitions def-or-expr ...). I am not sure whether or how this would conflict with optimization. Jos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
An hour ago, Matthew Flatt wrote: At Mon, 11 Oct 2010 20:38:58 -0400, Eli Barzilay wrote: At Mon, 11 Oct 2010 19:15:09 -0400, Eli Barzilay wrote: I'd love to see an implicit `#%begin', which could have the above apply in more places automatically. (It was one of the feature requests I asked for in the summer meeting.) Recall that no one solved the technical problem with where to pull the lexical context for the implicit `#%begin' or `#%body': http://lists.racket-lang.org/dev/archive/2010-July/003624.html I remember being confused with how that problem would look like, but I don't think that I've seen an example where this would be problematic. (I think that we talked about it, but I can't remember any concrete details...) Can you say more about how the `squawk' example in the referenced post doesn't illustrate the problem? It doesn't specify any clear problem -- either that or I'm missing something obvious... AFAICT, the problem that is described there is similar to: (define-syntax-rule (squawk body ...) (begin (printf squick ~a! squawk) (let () body ...))) having the implicit `#%app' come from this macro's module rather than the use site, for example, if it's defined in a module that has implicitlty curried applications then the `printf' call becomes curried. So if this is the problem, it doesn't seem problematic, given that `#%app' does the same now, and that it's easy to get used to that. But it looks to me like there is something that I'm missing, since that `#%app' feature doesn't require going to identifier macros... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
Three minutes ago, Matthew Flatt wrote: At Tue, 12 Oct 2010 10:43:03 -0400, Eli Barzilay wrote: An hour ago, Matthew Flatt wrote: At Mon, 11 Oct 2010 20:38:58 -0400, Eli Barzilay wrote: At Mon, 11 Oct 2010 19:15:09 -0400, Eli Barzilay wrote: I'd love to see an implicit `#%begin', which could have the above apply in more places automatically. (It was one of the feature requests I asked for in the summer meeting.) Recall that no one solved the technical problem with where to pull the lexical context for the implicit `#%begin' or `#%body': http://lists.racket-lang.org/dev/archive/2010-July/003624.html I remember being confused with how that problem would look like, but I don't think that I've seen an example where this would be problematic. (I think that we talked about it, but I can't remember any concrete details...) Can you say more about how the `squawk' example in the referenced post doesn't illustrate the problem? It doesn't specify any clear problem -- either that or I'm missing something obvious... AFAICT, the problem that is described there is similar to: (define-syntax-rule (squawk body ...) (begin (printf squick ~a! squawk) (let () body ...))) having the implicit `#%app' come from this macro's module rather than the use site, for example, if it's defined in a module that has implicitlty curried applications then the `printf' call becomes curried. Isn't the point of a configurable implicit begin that `squawk' can inherit the implicit-begin behavior of the use site instead of the definition site? That is, the intent of the example is that the `squawk' syntactic form has a body, and body means whatever it's configured to mean at the use site. But the same thing happens with `#%app' right? And the macro writer gets to choose whether to use its own implicit application or the one from the macro use -- so why is this case worse than that? (That kind of choice looks like it must be there, since whatever it looks like, you (the macro author) can choose one of the two.) Other macros, meanwhile, may expand to uses of `let' where the body of the `let' is meant to be used as in the context of the definition site (probably because the body of that `let' is not supplied as an argument to the macro). So, how does a macro implementor make the distinction between those kinds of `let's? It still sounds like I'm missing something. If I write that `squawk' macro and if there's some way to make the implicit `#%begin' come from the macro call site, then what would I do if I don't want that? And if the goal is to make it easier to use the call site's implicit begin, then how about this: `let's expansion plants a `#%begin' with the same context as itself, so the `squawk' author can use the call-site `let' or use its own binding to get something else. How does that break? (I'm asking this mostly in an attempt to figure out the problem.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
At Tue, 12 Oct 2010 11:16:35 -0400, Eli Barzilay wrote: Three minutes ago, Matthew Flatt wrote: At Tue, 12 Oct 2010 10:43:03 -0400, Eli Barzilay wrote: An hour ago, Matthew Flatt wrote: At Mon, 11 Oct 2010 20:38:58 -0400, Eli Barzilay wrote: At Mon, 11 Oct 2010 19:15:09 -0400, Eli Barzilay wrote: I'd love to see an implicit `#%begin', which could have the above apply in more places automatically. (It was one of the feature requests I asked for in the summer meeting.) Recall that no one solved the technical problem with where to pull the lexical context for the implicit `#%begin' or `#%body': http://lists.racket-lang.org/dev/archive/2010-July/003624.html I remember being confused with how that problem would look like, but I don't think that I've seen an example where this would be problematic. (I think that we talked about it, but I can't remember any concrete details...) Can you say more about how the `squawk' example in the referenced post doesn't illustrate the problem? It doesn't specify any clear problem -- either that or I'm missing something obvious... AFAICT, the problem that is described there is similar to: (define-syntax-rule (squawk body ...) (begin (printf squick ~a! squawk) (let () body ...))) having the implicit `#%app' come from this macro's module rather than the use site, for example, if it's defined in a module that has implicitlty curried applications then the `printf' call becomes curried. Isn't the point of a configurable implicit begin that `squawk' can inherit the implicit-begin behavior of the use site instead of the definition site? That is, the intent of the example is that the `squawk' syntactic form has a body, and body means whatever it's configured to mean at the use site. But the same thing happens with `#%app' right? Rarely. Very few syntactic forms expand to applications that are intended to use the `#%app' of the use site. And the macro writer gets to choose whether to use its own implicit application or the one from the macro use -- so why is this case worse than that? Because wanting `#%app' from the use site is very rare, while wanting implicit-begin from the use site looks very common. (That kind of choice looks like it must be there, since whatever it looks like, you (the macro author) can choose one of the two.) In the case of `#%app', you choose the original context attaching it to the relevant parentheses. Another problem for `#%body' is that there are no such parentheses to attach to. Other macros, meanwhile, may expand to uses of `let' where the body of the `let' is meant to be used as in the context of the definition site (probably because the body of that `let' is not supplied as an argument to the macro). So, how does a macro implementor make the distinction between those kinds of `let's? It still sounds like I'm missing something. If I write that `squawk' macro and if there's some way to make the implicit `#%begin' come from the macro call site, then what would I do if I don't want that? Yes, that's my question. And if the goal is to make it easier to use the call site's implicit begin, then how about this: `let's expansion plants a `#%begin' with the same context as itself, so the `squawk' author can use the call-site `let' or use its own binding to get something else. How does that break? (I'm asking this mostly in an attempt to figure out the problem.) How did you get the call-site `let'? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto neil.toro...@gmail.com wrote: If I get a vote, +1/2 from me. My vote isn't +1 because I'd rather see a syntactic restriction removed: make the inside of a `begin' an internal definition context. Then the change would happen in every similar macro at once. Would it break much? BEGIN is overloaded as a `splicing' macro. When you have a single macro call that needs to expand into multiple `actions', you return the actions within a BEGIN, and they are `flattened' into the containing context. Automagically introducing a new scope would break this behavior. It might be a good idea to introduce some sort of specific macro-splicing special form. -- ~jrm _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
On Mon, Oct 11, 2010 at 2:10 PM, Joe Marshall jmarsh...@alum.mit.edu wrote: On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto neil.toro...@gmail.com wrote: If I get a vote, +1/2 from me. My vote isn't +1 because I'd rather see a syntactic restriction removed: make the inside of a `begin' an internal definition context. Then the change would happen in every similar macro at once. Would it break much? BEGIN is overloaded as a `splicing' macro. When you have a single macro call that needs to expand into multiple `actions', you return the actions within a BEGIN, and they are `flattened' into the containing context. Automagically introducing a new scope would break this behavior. It might be a good idea to introduce some sort of specific macro-splicing special form. begin is already context-sensitive: as an expression, it expects a sequence of expressions; at the top-level or in a module, it expects a sequence of definitions mixed with expressions; and in internal definition contexts, it expects a sequence of definitions followed by a sequence of expressions. It would presumably not be that hard to just change the first case, so that as an expression it introduces a new scope and accepts definitions, while in the other cases it splices into an existing scope. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
Yesterday, Robby Findler wrote: Maybe you're saying that people would be confused by that error? Woudln't that already happen with (define (foo x) (define x (add1 x)) x) ? Yes, they would. I just think that overall more newbies fall for the trap of trying a conditional definition, so making it work (in a few more cases) might be confusing. In any case, I still like to have this feature -- I just mentioned the above to be fair. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
40 minutes ago, Matthew Flatt wrote: I agree about changing `when', `unless', and `cond'. I can't see changing `begin', especially now that internal-definition contexts allow a mixture of definitions and expressions. Unlike changing `when' and `unless', changing `begin' could change some existing programs, such as (let () (begin (define x 1) x) x) where that `begin' is a splicing `begin', since it's in an internal-definition context. Yes, it's the (imaginary) implicit begin that would change, so the above wouldn't change. In some future language, we should get rid of the overloading of `begin' for splicing and sequencing, but it would be painful to change right now. (+1) At Mon, 11 Oct 2010 19:15:09 -0400, Eli Barzilay wrote: I'd love to see an implicit `#%begin', which could have the above apply in more places automatically. (It was one of the feature requests I asked for in the summer meeting.) Recall that no one solved the technical problem with where to pull the lexical context for the implicit `#%begin' or `#%body': http://lists.racket-lang.org/dev/archive/2010-July/003624.html I remember being confused with how that problem would look like, but I don't think that I've seen an example where this would be problematic. (I think that we talked about it, but I can't remember any concrete details...) In any case, I did remember that it was problematic... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] `cond' / `when' / `unless' / etc bodies
I like mixing definitions and expressions -- maybe the bodies of `cond' etc should also allow it? The only downside I see is the possible confusion in somthing like (define (foo x) (when (even? x) (define x (add1 x)) (printf increment\n)) x) ;; why isn't this working? but that seems like a minor point (without that `printf' you'd still get a syntax error; and the same confusion can already happen with `let' etc). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
2010/10/10 Eli Barzilay e...@barzilay.org: I like mixing definitions and expressions -- maybe the bodies of `cond' etc should also allow it? In (define (foo x) (when (even? x) (define x (add1 x)) (printf increment\n)) x) is the scope of the definition (define x ...) the entire body of foo ? -- Jens Axel Søgaard _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] `cond' / `when' / `unless' / etc bodies
On Oct 10, 2010, at 2:43 PM, Robby Findler wrote: I too am in favor of when, unless, and cond being definition contexts. +1. I routinely wrap cond/when in let () for just that purpose. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
