Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
12 hours ago, John Clements wrote: What Eli is proposing, AFAICT, is not in fact a new abstraction, but a more disciplined--I might say, way *too* disciplined--use of the ones we have. Let me put it in concrete terms: I'm the author of racket/private/promise -- there's now a piece of code there that I don't understand. So if there's a bug there, my options are to ignore it and pass it onto Stephen (bad, since it's my code and he might not be aware of all the details), fix it myself (bad, because I don't have a clear idea what the code is supposed to do, and will likely break it), or start a discussion (with Stephen and/or you) about how the code needs to change -- which is the best option, but the worst in terms of getting the bug resolved. Even worse, what happens if you both move away[*] -- then I my options are to look at the source myself, or break the stepper. Or if all three of us are moving away, then someone needs to learn parts from two non-trivial systems to fix the bugs. It shouldn't be surprising now that I disagree with the *too*. ([*] Even if this is unlikely, I'm thinking about this from a maintenance point of view, where such questions are very obvious.) -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 16, 2011, at 7:39 PM, Matthias Felleisen wrote: On Aug 16, 2011, at 5:42 PM, Sam Tobin-Hochstadt wrote: On Tue, Aug 16, 2011 at 5:31 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. Aren't syntax properties precisely this abstraction? It is a mechanism and as such it is an abstraction. But is it the best possible abstraction? The use of symbols means the use of a protocol: when I see 'x, I will perform action A. So the identity of the symbol is critical. And that means we're tying together the two (+) components that are subject to the protocol. If the symbol changes in one of them, the other one breaks (the type checker, the stepper). That's Dan's rule: don't use symbols to impose protocols. (Today's add1 day for Dan.) What you really want is a name (variable). So at a minimum, two components should rely on a shared module that exports a variable to be used instead of a symbol. Then you could use (gensym) and nobody could mess with the symbol. Identity would be enforced afresh every time you start the system. But once you introduce a random name, you see that you want some other mechanism that 'mixes' into the compilation process as needed. I don't see this. In fact, I believe that the existing syntax system probably already supports this, in allowing the use of non-symbols as syntax-property keys. I just use symbols to increase transparency. What Eli is proposing, AFAICT, is not in fact a new abstraction, but a more disciplined--I might say, way *too* disciplined--use of the ones we have. In particular, the code for the teaching languages currently has many points where a syntax-property is added saying, in effect, the stepper needs to treat this piece specially. There are many instances of this that could probably be cleaned up and eliminated. For instance, the stepper has a 'stepper-binding-type' property, used thusly (from internal-docs.txt): stepper-binding-type : this is actually unrelated to macro expansion. It differentiates between the various kinds of lexical bindings. [ 'macro-bound ] : this variable's binding was inserted by a macro [ 'let-bound ] : this variable's binding was in a let/*/rec [ 'lambda-bound ] : this variable's binding was in a lambda [ 'non-lexical ] : this variable's identifier-binding is not 'lexical (i.e., unbound, top-level, or a module binding My guess is that in 2011, this information can probably be recovered from the syntax tree somehow. On the other hand, there are properties like this one: stepper-replace : This is like stepper-skipto/discard, except that it makes the stepper replace the expression the property is attached to by the value of the property. ... which is a straight-up cheat: it's saying, hey stepper, use this expression instead of the one that you think should go here. I would have to see exactly where this one is used, to see whether there's a more general way to tackle this. In general, then, I think that Eli's suggestions are sensible; I'm just not sure whether the payoff is worth the cost. John p.s.: I *still* think that the ability to place guards on syntax properties could be a big win. In fact, one advantage of not using symbols here is that you could perhaps check this statically. smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
Earlier today, Stephen Chang wrote: It seems like most people agree that it's ok to add stepper syntax properties to lazy racket. I agree with that in general while development is ongoing, but eventually it should be disconnected too. The problem is that the lazy language is split between two files: lazy/lazy.rkt and racket/private/promise.rkt, with promise.rkt also trying to be a generic library at the same time. That, I *strongly* object to! The promise implementation is just that. It is *not* a part of the lazy language implementation in a similar way that `car' is not a part of the implementation of languages that happen to use it. That was fine when a third party didnt need to communicate something to both files at once but now the stepper does. The duplicated function, stepper-syntax-property, is just syntax-property with a 'stepper key. If I do what Eli says and only use generic documented functions in promise.rkt, I can use syntax-property, but I still need to somehow communicate the 'stepper key to both lazy.rkt and promise.rkt. What I object to is the property name, and more importantly, writing code that is aware that there is a bag of stepper properties. We can deal with plain properties just fine, and if a property is generic enough it should be describable independently. (And if there's no easy way to describe it independently, then most likely it should go away from the general API.) Other languages wont have this problem because the implementation is likely all in one place. Other tools for lazy racket may have this problem if they need to communicate something to both lazy.rkt and promise.rkt, but could possibly get away with it if everything can be done in the lazy.rkt section of the language. Lazy is indeed a major client for (composable) promises, but it's not the only one. This fact makes it unsurprising that things that the lazy implementation needs tend to motivate designing and extending the promise API, but that API is still independent. -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
Three minutes ago, John Clements wrote: On Aug 16, 2011, at 4:41 PM, Eli Barzilay wrote: Earlier today, Stephen Chang wrote: It seems like most people agree that it's ok to add stepper syntax properties to lazy racket. I agree with that in general while development is ongoing, but eventually it should be disconnected too. I don't see how to do this. To make sure we're on the same page, I'm suggesting that it's very difficult to make statements about places in the expanded code without adding annotations to the text of the expansions themselves. A possible conclusion would be that it's useful to know these kind of things about an expanded piece of syntax, and therefore more macros should do that -- but that's unrelated from the stepper, which is merely the motivation for requiring such functionality. Just like continuation marks being useful for the stepper, becoming part of the core language, and then getting used for much more. -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 16, 2011, at 5:10 PM, Eli Barzilay wrote: Three minutes ago, John Clements wrote: On Aug 16, 2011, at 4:41 PM, Eli Barzilay wrote: Earlier today, Stephen Chang wrote: It seems like most people agree that it's ok to add stepper syntax properties to lazy racket. I agree with that in general while development is ongoing, but eventually it should be disconnected too. I don't see how to do this. To make sure we're on the same page, I'm suggesting that it's very difficult to make statements about places in the expanded code without adding annotations to the text of the expansions themselves. A possible conclusion would be that it's useful to know these kind of things about an expanded piece of syntax, and therefore more macros should do that -- but that's unrelated from the stepper, which is merely the motivation for requiring such functionality. Just like continuation marks being useful for the stepper, becoming part of the core language, and then getting used for much more. I believe I disagree, but we're still being way too vague. For instance, consider the stepper-skipto annotations, that specify where in an expanded expression the user's original code wound up. On the one hand, you could argue that finding the original expression is a general concept, and could be useful independent of the stepper, but in the absence of other tools that need to know this, the extra work of developing and documenting this general mechanism would seem to constitute a dramatic example of premature abstraction. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
Four minutes ago, John Clements wrote: On Aug 16, 2011, at 5:10 PM, Eli Barzilay wrote: A possible conclusion would be that it's useful to know these kind of things about an expanded piece of syntax, and therefore more macros should do that -- but that's unrelated from the stepper, which is merely the motivation for requiring such functionality. Just like continuation marks being useful for the stepper, becoming part of the core language, and then getting used for much more. I believe I disagree, but we're still being way too vague. For instance, consider the stepper-skipto annotations, that specify where in an expanded expression the user's original code wound up. On the one hand, you could argue that finding the original expression is a general concept, and could be useful independent of the stepper, but in the absence of other tools that need to know this, the extra work of developing and documenting this general mechanism would seem to constitute a dramatic example of premature abstraction. What I'd argue is: 1. There might be a way to get the same without those annotations. There's the `syntax-original?' thing, source locations etc. Perhaps it is not possible only because some of these need to change in minor ways. 2. I'm not sure about the exact details, but there are other uses for such functionality (or at least something very similar to it). For example, there's code that I wrote a while ago to find parts of an expression that come from the original code for making TR errors readable. (Something that I completely forgot that I did, until we talked about it in rcon.) 3. Combining #2 with the fact that the stepper has been around for ever (racketly speaking), I don't think that it's premature to talk about a general abstaction. -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
6 minutes ago, Matthias Felleisen wrote: Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. Maybe a good (re-)start would be to specify the required functionality more precisely? Maybe follow the recipe and start with short examples of what's needed? -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
On Tue, Aug 16, 2011 at 5:31 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. Aren't syntax properties precisely this abstraction? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 16, 2011, at 5:42 PM, Sam Tobin-Hochstadt wrote: On Tue, Aug 16, 2011 at 5:31 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. Aren't syntax properties precisely this abstraction? It is a mechanism and as such it is an abstraction. But is it the best possible abstraction? The use of symbols means the use of a protocol: when I see 'x, I will perform action A. So the identity of the symbol is critical. And that means we're tying together the two (+) components that are subject to the protocol. If the symbol changes in one of them, the other one breaks (the type checker, the stepper). That's Dan's rule: don't use symbols to impose protocols. (Today's add1 day for Dan.) What you really want is a name (variable). So at a minimum, two components should rely on a shared module that exports a variable to be used instead of a symbol. Then you could use (gensym) and nobody could mess with the symbol. Identity would be enforced afresh every time you start the system. But once you introduce a random name, you see that you want some other mechanism that 'mixes' into the compilation process as needed. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011, at 10:44 AM, John Clements wrote: Adding dev to followups, hope that's okay with all three of you. On Aug 12, 2011, at 7:15 PM, Eli Barzilay wrote: A few seconds ago, Matthias Felleisen wrote: This sounds wrong. The only way there can be a dependency is via require. So how can it not be checkable, never mind copy or hand-coding. The stepper has some function that annotates syntaxes with a stepper specific value. Stephen wanted to use this function but couldn't because there was a dependency cycle. So to resolve it, he copied the function into `racket/private/promise' -- so now there's a bit of stepper code that is duplicated in the core. The duplication is obvious problem #1. The more subtle problem is the existence of code in the core that has no meaning without the stepper. I'm coming a bit late to this party, but I disagree with at least some of this. Actually, I want to disagree mostly with the more subtle problem. To start with, here's the basic motivating change to the code (lots like this): - (defsubst (~and x ...) (~ (and (! x) ...)) ~and *and) + (defsubst (~and x ...) (hidden-~ (and (hidden-! x) ...)) ~and *and) One more minor aside I should have mentioned: Stephen's use of a macro here reads *much more nicely* than the way the rest of the stepper annotations explicitly inject the annotations using with-syntax; when I get time, I want to adopt this approach elsewhere. Nice! John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011, at 10:44 AM, John Clements wrote: That is, the code for lazy racket contains the knowledge about which things should be hidden by the stepper. I would argue, in fact, that this is the *right* place for such knowledge. In particular, suppose you're developing the lazy stepper, and you want to say, this thing here is hidden. How do you point to a particular expansion? You want to make an annotation in the code for the expansion itself. The alternatives I can think of are all hideously fragile, unless you go to some AOSD approach, but I think that this would wind up being even more verbose, and not substantially less fragile. That is, I think that the subtle problem above is not actually a problem at all. Let me try to say what I understand out loud: 1. The existence of Stepper knowledge in the Lazy compiler creates a 'spiritual' dependency between the Lazy language and a tool in DrRacket (= Tool world). QUESTION: does this knowledge ever make sense outside of our tool suite? Could it be reused by a stack-tracing debuggger in a textual repl? 2. At the same time, this Tool knowledge is best injected into compilation just in case we want it. QUESTION: does some knowledge about Lazy compilation move into the Stepper if we don't inject the knowledge here? 3. I agree with John though I am actually hopeful that we can come up with a software architecture that eliminates the problem and isn't AOSD all the way. Is it possible to view this knowledge as a mixin that gets added to the Lazy compiler when the language lives in the Tool world? -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
Doesn't the same problem exist for other tools, such as the Tracer? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
FWIW, there is precedent for this kind of thing, namely the properties that get added to syntax objects to tell check syntax about bindings that aren't in the fully expanded program (and yeah, I know there is a pending question about this; sorry I haven't had time to look into it and straighten things out). Syntax properties generally seem like a good vehicle for languages/macros to communicate information to tools. Robby On Sat, Aug 13, 2011 at 10:22 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 10:44 AM, John Clements wrote: That is, the code for lazy racket contains the knowledge about which things should be hidden by the stepper. I would argue, in fact, that this is the *right* place for such knowledge. In particular, suppose you're developing the lazy stepper, and you want to say, this thing here is hidden. How do you point to a particular expansion? You want to make an annotation in the code for the expansion itself. The alternatives I can think of are all hideously fragile, unless you go to some AOSD approach, but I think that this would wind up being even more verbose, and not substantially less fragile. That is, I think that the subtle problem above is not actually a problem at all. Let me try to say what I understand out loud: 1. The existence of Stepper knowledge in the Lazy compiler creates a 'spiritual' dependency between the Lazy language and a tool in DrRacket (= Tool world). QUESTION: does this knowledge ever make sense outside of our tool suite? Could it be reused by a stack-tracing debuggger in a textual repl? 2. At the same time, this Tool knowledge is best injected into compilation just in case we want it. QUESTION: does some knowledge about Lazy compilation move into the Stepper if we don't inject the knowledge here? 3. I agree with John though I am actually hopeful that we can come up with a software architecture that eliminates the problem and isn't AOSD all the way. Is it possible to view this knowledge as a mixin that gets added to the Lazy compiler when the language lives in the Tool world? -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011, at 11:33 AM, Robby Findler wrote: FWIW, there is precedent for this kind of thing, namely the properties that get added to syntax objects to tell check syntax about bindings that aren't in the fully expanded program (and yeah, I know there is a pending question about this; sorry I haven't had time to look into it and straighten things out). Syntax properties generally seem like a good vehicle for languages/macros to communicate information to tools. Totally, agree, natch. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Sam _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011, at 1:34 PM, Carl Eastlund wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. I feel we're getting perilously close to writing a paper about the essence of AOSD Regard a piece of code as a machine. Not a specification of a machine, but the actual machine. Now, tools like the stepper and typechecker need to be able to refer to that part of the machine, right there. There are various ways of doing it, but what we've chosen to do (add a piece to the machine that's superfluous except when the machine is run using a particular mode or tool) has the advantage that it's robust. It doesn't necessarily break when other parts of the code around it change, and it's obvious to anyone modifying the code that you need to think about that annotation when you change the code. I could imagine a tool that allowed such annotations to be automatically hidden, so that the underlying code is clearer, but I can't see a better way of separating these concerns. Am I missing something? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
Two minutes ago, Sam Tobin-Hochstadt wrote: On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. +1. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. To rephrase what Carl said: what if you change the TR type chekcer to a type verifier? You'd change the property name, which means that a TR change has lead to a change in match. That's the actual dependency. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Exactly -- having typechecker: in the name is bogus. Would you mind changing it to `swindle:called-in-tail-position'? -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
On Sat, Aug 13, 2011 at 2:05 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Sam How do I know it means that? Is the correspondence between this let-bound function is probably called in tail position and the value of the typechecker:called-in-tail-position property documented outside of the typechecker? The precise intended meaning of the syntax property is not immediately obvious just from its name. If it is documented outside of the typechecker, why does it start with typechecker:? --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011 2:13 PM, Eli Barzilay e...@barzilay.org wrote: Two minutes ago, Sam Tobin-Hochstadt wrote: On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. +1. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. To rephrase what Carl said: what if you change the TR type chekcer to a type verifier? You'd change the property name, which means that a TR change has lead to a change in match. That's the actual dependency. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Exactly -- having typechecker: in the name is bogus. Would you mind changing it to `swindle:called-in-tail-position'? Is this just an argument about how to name these syntax properties? If so, I'm happy with whatever you think I should name it. That doesn't seem to get us anywhere on the other questions, though. Sam _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
5 minutes ago, John Clements wrote: On Aug 13, 2011, at 1:34 PM, Carl Eastlund wrote: How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. I feel we're getting perilously close to writing a paper about the essence of AOSD Actually all of my (admittedly pretty limited) experience with any kind of AOP is that the problem is resolved by mutating hook values. The same as adding methods to generic functions is done in CLOS. Regard a piece of code as a machine. Not a specification of a machine, but the actual machine. Now, tools like the stepper and typechecker need to be able to refer to that part of the machine, right there. There are various ways of doing it, but what we've chosen to do (add a piece to the machine that's superfluous except when the machine is run using a particular mode or tool) has the advantage that it's robust. It's true that you avoid such mutation which makes things more robust. But from a SD perspective, I see it as making things less robust... It doesn't necessarily break when other parts of the code around it change, and it's obvious to anyone modifying the code that you need to think about that annotation when you change the code. ...and that's a good explanation why I see it as less robust: currently, I'm responsible for the code in `racket/private/promise'. I knew that code well, and I could fix it, extend it, etc. But now there's a part of that code that I have no knowledge of -- it stands in the way of me doing this kind of work. It's now preconditioned with me passing changes onto Stephen to approve, or study the stepper to know how it should change. On the other hand, if the property is made *completely* independent of the stepper (in name, functoinality, implementation, and spirit), then I'd have some explanation of the property that I could use to know how to deal with that piece of code when I do such revisions. The same exact thing holds for Sam's `match' hack: just having a typechecker in the name means that the `match' maintainer[*] wouldn't just change that code without asking Sam about it -- since it's not clear what the semantics of that thing is. In that sense it is very different from `disappeared-use', which is a concept that does not depend on the syntax cheker. [*] The fact that they're the same person is probably a strong reason that this dependency happened in the first place. If someone else would maintain `match', then Sam would need to convince that person that they should add it, and my guess is that most reasonable people would object to adding arbitrary names into their code. -- ((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] syntax-property guards? (was: Re: The Stepper strikes again)
10 minutes ago, Sam Tobin-Hochstadt wrote: Is this just an argument about how to name these syntax properties? Yes -- and that leads to more than just the name. If so, I'm happy with whatever you think I should name it. That doesn't seem to get us anywhere on the other questions, though. Sure it does. Here's an attempt to clarify how: Currently, there's a weird `typechecker:called-in-tail-position' name that means nothing to anyone other than the people who know what the `typechecker' is. If it's changed from that into just `called-in-tail-position', then you get a bunch of good results: * Above all, it means that it's now an extension for (macros in) the core language -- it's properly documented in a way that makes it possible for me to use it as both a client of such macros and as a writer of them. * This would be documented in a section of the core reference that lists all kinds of properties that I should be aware of when I'm writing macros. The `disappeared-use' property should be documented there too (I see that it's not documented at all now), as well as the stepper property that Stephen added would be there too. The `inferred-name' property is part of the same thing. (Obviously, adding such things should be minimized, so that simple macros don't need to deal with any of them, and it's only certain kinds of macros that don't get the it just work property.) * As a client, I can now write additional tools that can tell when something is intended only for tail calls. I can imagine a bunch of uses for such a thing. The benefit here is obvious. * As an author, it's clear now that if I write a macro that binds a function that is called only in tail position, then I should signal that intention via specifying this property. The benefit here is that TR can now work better since there are additional macros that it will know how to deal with. But it can then go beyond those benefits: * At the level of core design, you've essentially identified a feature that you need to use in TR, and that you cannot get without explicit marking done by macro authors. A weak point in this is that you're allowing random marks made by random macros -- my guess is that this makes for an easy way to break TR. * This means that there's benefit for having this done in a reliable way, which means that it's a good argument for the core language to make that information available automatically, in a way that cannot be faked by random macros. Either that, or if it's not possible, have the core verify it in some way -- like throwing a syntax error when such expressions are used in non-tail positions. -- ((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
