Re: [racket-dev] Blame and re-provided bindings
On Sun, Jan 16, 2011 at 10:03 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jan 15, 2011, at 5:05 PM, Casey Klein wrote: On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 15, 2011, at 12:19 PM, Robby Findler wrote: I think that we are just throwing up stumbling blocks. It is really a design choice (does a reprovide carry over the contract or does it put a new one on there?) and I seriously doubt there are any places where someone does a reprovide intending to change the contract in this manner. To the contrary, I expect that nearly every place where someone does a reprovide, they indented to use the exact same contract (with different parties now). This is possible, but _which_ parties? Do you wish to export internals through an external interface that should now take on the positive blame, so that you don't leak your internals (via module names and such used as blame parties)? This seems to me what you'd want for something like redex [...] No, that's not the use case. There are three modules, each of which is an external interface: 1. redex/reduction-semantics, which provides the non-GUI portion of Redex, 2. redex/pict, which provides the typesetting utilities, and 3. redex, which provides all of redex/reduction-semantics and redex/pict, plus some more. The redex module does an all-from-out provide on what it gets from redex/reduction-semantics and redex/pict, making it the negative party on the contracts. When a redex client breaks one of the contracts, redex gets blamed instead of the client. This sounds like a plain bug. Yes, it's definitely a bug (in Redex). All I want is a convenient way to fix the bug. Naming all the contracts and applying them at both levels seems pretty cumbersome, even with macros. (But I do share Robby's concern that the easy way to reprovide is not the right way to reprovide.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Sun, Jan 16, 2011 at 10:03 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jan 15, 2011, at 5:05 PM, Casey Klein wrote: On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 15, 2011, at 12:19 PM, Robby Findler wrote: I think that we are just throwing up stumbling blocks. It is really a design choice (does a reprovide carry over the contract or does it put a new one on there?) and I seriously doubt there are any places where someone does a reprovide intending to change the contract in this manner. To the contrary, I expect that nearly every place where someone does a reprovide, they indented to use the exact same contract (with different parties now). This is possible, but _which_ parties? Do you wish to export internals through an external interface that should now take on the positive blame, so that you don't leak your internals (via module names and such used as blame parties)? This seems to me what you'd want for something like redex [...] No, that's not the use case. There are three modules, each of which is an external interface: 1. redex/reduction-semantics, which provides the non-GUI portion of Redex, 2. redex/pict, which provides the typesetting utilities, and 3. redex, which provides all of redex/reduction-semantics and redex/pict, plus some more. The redex module does an all-from-out provide on what it gets from redex/reduction-semantics and redex/pict, making it the negative party on the contracts. When a redex client breaks one of the contracts, redex gets blamed instead of the client. This sounds like a plain bug. Matthias: I believe that this is the behavior you were arguing for upthread. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Jan 17, 2011, at 9:00 AM, Robby Findler wrote: The redex module does an all-from-out provide on what it gets from redex/reduction-semantics and redex/pict, making it the negative party on the contracts. When a redex client breaks one of the contracts, redex gets blamed instead of the client. This sounds like a plain bug. Matthias: I believe that this is the behavior you were arguing for upthread. Thanks for putting it so plain. Casey writes: (1) the client of redex breaks one of the contracts. (2) redex gets blamed These two sentences next to each other made no sense to me, whatsoever. Now I understand what they mean: (1) the client breaks the contract of 'private' module A (2) and the redex 'super' module M gets blamed because it re-exports all of A's functionality with any/c I understand, and yes, this is my preference. But as I have said before, I can see a case for convenience -- as long as Carl's constraints are satisfied too. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
So far as I understand it, we have: Stevie opposed, Matthias neutral, Robby and Casey for, with everyone agreeing that we should try to preserve the Carl constraints of 'single contract wrapper' and 'same identifier-ness'. Note that in the current world we are *forced* to break the first of the Carl constraints. So I consider this a bonus if we achieve it (and so if we don't in some cases, I don't think we should care). Is that a correct summary of the status? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Building without docs
Well, that didn't work, but we've decided to upgrade to Racket anyway :) What's the equivalent process for Racket? Thanks, N. On Wed, Jan 12, 2011 at 12:58 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 12 Jan 2011 11:29:03 +, Noel Welsh wrote: I'm trying to build 4.2.2 without building the docs. I thought I could just run make and then setup-plt -D, but make does not install the binaries. Looking through the Makefile did not lead to enlightenment. Any suggestions? Does `make plain-install' followed by `setup-plt -D' work? (Version 4.2.2 is old enough that I forget what worked back then.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler ro...@eecs.northwestern.edu wrote: So far as I understand it, we have: Stevie opposed, Matthias neutral, Robby and Casey for, with everyone agreeing that we should try to preserve the Carl constraints of 'single contract wrapper' and 'same identifier-ness'. Note that in the current world we are *forced* to break the first of the Carl constraints. So I consider this a bonus if we achieve it (and so if we don't in some cases, I don't think we should care). Is that a correct summary of the status? Given the performance impacts of rewrapping, it seems like solving that problem should be a prerequisite for changing the semantics of `provide' to automatically add non-trivial contracts. I think it would be pretty problematic to suddenly add repeated list traversals to any code that reprovides identifiers. At the moment, we're force to rewrap to get the right semantics. That is, show me a (real) module that re-exports contracts with any/c and I'll show you a way to blame that module and the solution will have to be a rewrapping (or a moving of the contracts). And I'm talking about real code, not made up examples, of course. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Building without docs
You can also set PLT_SETUP_OPTIONS to -D and then make install will avoid building the docs. Also note that on a multi-core machine make -j N works and speeds things up a bit. Robby On Mon, Jan 17, 2011 at 9:02 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Jan 17, 2011 at 10:01 AM, Noel Welsh noelwe...@gmail.com wrote: Well, that didn't work, but we've decided to upgrade to Racket anyway :) What's the equivalent process for Racket? Very similar: % make % make plain-install % raco setup -D Thanks, N. On Wed, Jan 12, 2011 at 12:58 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 12 Jan 2011 11:29:03 +, Noel Welsh wrote: I'm trying to build 4.2.2 without building the docs. I thought I could just run make and then setup-plt -D, but make does not install the binaries. Looking through the Makefile did not lead to enlightenment. Any suggestions? Does `make plain-install' followed by `setup-plt -D' work? (Version 4.2.2 is old enough that I forget what worked back then.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ 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] Blame and re-provided bindings
On Jan 17, 2011, at 10:10 AM, Robby Findler wrote: On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler ro...@eecs.northwestern.edu wrote: So far as I understand it, we have: Stevie opposed, Matthias neutral, Robby and Casey for, with everyone agreeing that we should try to preserve the Carl constraints of 'single contract wrapper' and 'same identifier-ness'. Note that in the current world we are *forced* to break the first of the Carl constraints. So I consider this a bonus if we achieve it (and so if we don't in some cases, I don't think we should care). Is that a correct summary of the status? Given the performance impacts of rewrapping, it seems like solving that problem should be a prerequisite for changing the semantics of `provide' to automatically add non-trivial contracts. I think it would be pretty problematic to suddenly add repeated list traversals to any code that reprovides identifiers. At the moment, we're force to rewrap to get the right semantics. That is, show me a (real) module that re-exports contracts with any/c and I'll show you a way to blame that module and the solution will have to be a rewrapping (or a moving of the contracts). And I'm talking about real code, not made up examples, of course. My hunch is that the proper response to Sam is to remove the contracts from 'private' modules to reduce the double hit. In a sense I was hoping that this would happen if we forced deveoplers to re-state the contract if re-provide means any/c. But I guess this is not going to happen. But I do see Sam's reply as another argument against implicit rewrapping given the implicit performance hit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Mon, Jan 17, 2011 at 9:28 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jan 17, 2011, at 10:10 AM, Robby Findler wrote: On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler ro...@eecs.northwestern.edu wrote: So far as I understand it, we have: Stevie opposed, Matthias neutral, Robby and Casey for, with everyone agreeing that we should try to preserve the Carl constraints of 'single contract wrapper' and 'same identifier-ness'. Note that in the current world we are *forced* to break the first of the Carl constraints. So I consider this a bonus if we achieve it (and so if we don't in some cases, I don't think we should care). Is that a correct summary of the status? Given the performance impacts of rewrapping, it seems like solving that problem should be a prerequisite for changing the semantics of `provide' to automatically add non-trivial contracts. I think it would be pretty problematic to suddenly add repeated list traversals to any code that reprovides identifiers. At the moment, we're force to rewrap to get the right semantics. That is, show me a (real) module that re-exports contracts with any/c and I'll show you a way to blame that module and the solution will have to be a rewrapping (or a moving of the contracts). And I'm talking about real code, not made up examples, of course. My hunch is that the proper response to Sam is to remove the contracts from 'private' modules to reduce the double hit. In a sense I was hoping that this would happen if we forced deveoplers to re-state the contract if re-provide means any/c. But I guess this is not going to happen. I refer you to Casey's message again. That isn't possible in general. You'd have to go to a much more complex setup, introducing another layer of files. But I do see Sam's reply as another argument against implicit rewrapping given the implicit performance hit. Yes and I said so in my message too. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Mon, Jan 17, 2011 at 9:49 AM, Robby Findler ro...@eecs.northwestern.edu wrote: [...] remove the contracts from 'private' modules to reduce the double hit. Let me summarize what was important in Casey's message that relates to this. He has these files: redex/gui.rkt redex/reduction-semantics.rkt redex/main.rkt The first two export subsets of the Redex library (in order to make it easy to depend only on parts of the rest of the system). The third one just re-exports the things from the other two. To do what you're proposing, he'd have to add three more files: 1 with the contracts, and two files that are un-contracted versions of the first two. Then, he'd have to write a bunch of boilerplate code to put all this together in the right way (or write a macro). It is this example that makes me think we (the contract system designers) are doing it wrong. In a sense I was hoping that this would happen if we forced deveoplers to re-state the contract if re-provide means any/c. But I guess this is not going to happen. FWIW, this smacks of an SML-ish way of thinking about this design decision. :) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Jan 17, 2011, at 10:53 AM, Robby Findler wrote: Let me summarize what was important in Casey's message that relates to this. He has these files: redex/gui.rkt redex/reduction-semantics.rkt redex/main.rkt The first two export subsets of the Redex library (in order to make it easy to depend only on parts of the rest of the system). The third one just re-exports the things from the other two. To do what you're proposing, he'd have to add three more files: 1 with the contracts, and two files that are un-contracted versions of the first two. Then, he'd have to write a bunch of boilerplate code to put all this together in the right way (or write a macro). It is this example that makes me think we (the contract system designers) are doing it wrong. I would expect this organization: redex/contracts redex/private/ : gui reduction-semantics redex/gui redex/reduction-semantics (ignoring that gr2 will make the logical separation superfluous). The problem is that the last two are thin 'generatable' modules over the ones in private. As far as I can see this organization isn't a problem of the contract system but a problem of the module system. In Racket, modules are first-order and it is difficult to abstract over the wrapper process. (I am not sure we could abstract over this process in the unit world.) In a sense I was hoping that this would happen if we forced deveoplers to re-state the contract if re-provide means any/c. But I guess this is not going to happen. FWIW, this smacks of an SML-ish way of thinking about this design decision. :) (1) The word 'smacks' suggests you're escaping from logical arguments and that you are alluding to emotional anti-SML sentiments. I'll ignore this aspect of your response. (2) SML isn't all wrong. Perhaps we can learn from them. (3) And no, I wasn't thinking of SML at all. I was thinking of our 'market-place' design forces via contracts. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Mon, Jan 17, 2011 at 10:10 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jan 17, 2011, at 10:53 AM, Robby Findler wrote: Let me summarize what was important in Casey's message that relates to this. He has these files: redex/gui.rkt redex/reduction-semantics.rkt redex/main.rkt The first two export subsets of the Redex library (in order to make it easy to depend only on parts of the rest of the system). The third one just re-exports the things from the other two. To do what you're proposing, he'd have to add three more files: 1 with the contracts, and two files that are un-contracted versions of the first two. Then, he'd have to write a bunch of boilerplate code to put all this together in the right way (or write a macro). It is this example that makes me think we (the contract system designers) are doing it wrong. I would expect this organization: redex/contracts (redex/private/contracts.rkt?) redex/private/ : gui reduction-semantics redex/gui redex/reduction-semantics The problem is that the last two are thin 'generatable' modules over the ones in private. Yes. That is the problem. We're forcing people to write roughly 3 lines for each provided variable (when they are in this multiple interfaces situation) in order to have a default that is, in practice, never the right thing. I have a hard time getting behind this design point. It feels like a lot of make-work. As far as I can see this organization isn't a problem of the contract system but a problem of the module system. In Racket, modules are first-order and it is difficult to abstract over the wrapper process. (I am not sure we could abstract over this process in the unit world.) That's also possible but, as you say, I'm not sure we'd abstract their either. And, in any case, we are talking about the module world. I think we agree that the right answer to the design choice we're debating is not to say use units, right? (ignoring that gr2 will make the logical separation superfluous). This is incorrect. The documentation libraries, for example, are not allowed to depend on racket/gui/base but redex/gui necessarily depends on racket/gui/base, so the separation is still important. (Maybe this will change more in the future, of course, but it won't change for 5.1, I'm pretty sure.) And maybe if you missed that, you might have (or maybe not, but this seems like a reasonable place to mention it -- no offense intended if you already got this bit) missed that racket/draw and racket/snip now exist one can use drawing libraries and snip libraries without depending on racket/gui/base (neither of those depend on racket/gui/base, that is). Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] input methods under Unix/X
2011/1/17 Matthew Flatt mfl...@cs.utah.edu: I've finally enabled input-method support in `racket/gui' under X. (Input methods have long been supported for Windows and Mac OS X.) Maybe it doesn't count as input method support, but I've recently switched to the Japanese localization of OS X with the Koeteri system and when I do not explicitly choose the Latin input method nothing appears in DrRacket when I type. (For example, normally (basically all other OS X apps) in hiragana mode when I type ichi it appears as いち for a moment, but when I press down I can change it to 一. But in DrRacket, nothing appears at all the whole time.) Jay One consequence of this change is that, under X, Shift-Ctl-U 3 B B Return probably inserts `λ' anywhere that you can type in a Racket GUI program, since Shift-Ctl-U triggers a mode in the default(?) Gtk input method to type Unicode characters by their hexadecimal code points. More usefully to many, CJK input should now work under Gtk. Key-event handling is complex, and there are lots of ways that this change could go wrong. Keep an eye out for new event-handling problems under X. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] input methods under Unix/X
At Mon, 17 Jan 2011 19:03:47 -0700, Jay McCarthy wrote: Maybe it doesn't count as input method support, but I've recently switched to the Japanese localization of OS X with the Koeteri system and when I do not explicitly choose the Latin input method nothing appears in DrRacket when I type. That definitely counts. I've pushed half a fix. The input state should work correctly now, but the state is mostly invisible up to the point that you commit characters to the editor. I hope to finish the other half of the fix (make the input state visible) soon. Pushing half a fix just lets Mac users can try out the first half right away, because the changes can easily affect other kinds of input. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
