Re: [racket-dev] Purpose of typed/racket/no-check
On Mar 31, 2013, at 9:32 PM, Sam Tobin-Hochstadt wrote: My expectation when using typed/racket/no-check is that I won't get any type errors. To me, the words no check mean just that: do not type-check the module. But I think it is okay to parse the types. I doubt people use this option when they wish to avoid a parse error in the type expressions. While `define-predicate` can't work in that sense, we could just make `cast` always succeed, which I think would be helpful. I only use no-check to take a file that won't typecheck due to some problem I hope to fix, and just run it. I think what you're suggesting would reduce its usefulness for some of those cases, and increase it in others. On Sun, Mar 31, 2013 at 5:44 PM, Eric Dobson eric.n.dob...@gmail.com wrote: There have been a couple recent bug reports because certain features need a type, such as cast and define-predicate. I was wondering whether TR/no-check should check that the types are well formed, but not check that the expressions are well typed? I'm thinking this would be less surprising to users, but wondering whether users would expect that type definition errors to still work in TR/no-check. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
Tell 12 year old middle school students. On Mar 31, 2013, at 9:15 PM, Sam Tobin-Hochstadt wrote: I said this to you in person, but I continue to think that 2htdp should just do away with the concept of teachpacks, and just use the require form always. Even today, it could insert a require instead of modifying hidden state. Sam On Mar 31, 2013 6:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Correct, and we have run into this image problem for a while now. I think the most important improvements are: 1. to swap the teachpack menus for 2e and 1e 2. to increase the titles of all three panes so that it becomes clear what you are dealing with Eventually the pane for 1e should become something almost hidden but we are not there yet. -- Matthias p.s. And yes, it would be nice if the window had a title such as add teachpacks On Mar 23, 2013, at 5:49 PM, Sam Tobin-Hochstadt wrote: Opening up the Add Teachpack dialog presents the user with two lists of libraries, which overlap in exactly one case: image.ss. This makes it very easy for the user to choose the old image.ss library when working with HtDP2e. Further, there's no indication in DrRacket as to which one of these was chosen. I can think of a couple ways this could be improved: the HtDP2e prologue could be explicit about which pane of the dialog to look in, and the dialog itself could ask the user which book they're using. Also, it would be great if DrRacket said Teachpack: image.ss (from HtDP) in the language position. Or we could just hide the old teachpack. Sam PS: the Add Teachpack dialog has no title on my machine, or rather it's just titled DrRacket. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Purpose of typed/racket/no-check
20 minutes ago, Matthias Felleisen wrote: On Mar 31, 2013, at 9:32 PM, Sam Tobin-Hochstadt wrote: My expectation when using typed/racket/no-check is that I won't get any type errors. To me, the words no check mean just that: do not type-check the module. But I think it is okay to parse the types. I doubt people use this option when they wish to avoid a parse error in the type expressions. As a semi-random data point, I sometime use my no-check language (which is built on top of TR's) to show how things work in class without getting all the types right (or when there's some problem with the types). In these cases I sometime use bogus type declarations like (All (A B) ...), which IIUC wouldn't work anymore. It's just technically simpler and clearer to still use `:' instead of going back to comments. (But it's obviously a weak point.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
I don't see why middle school students would have more trouble with `require` than with any other aspect of the system. Also, WeScheme just provides graphics libraries by default, which is another option we could consider. On Mon, Apr 1, 2013 at 9:10 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Tell 12 year old middle school students. On Mar 31, 2013, at 9:15 PM, Sam Tobin-Hochstadt wrote: I said this to you in person, but I continue to think that 2htdp should just do away with the concept of teachpacks, and just use the require form always. Even today, it could insert a require instead of modifying hidden state. Sam On Mar 31, 2013 6:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Correct, and we have run into this image problem for a while now. I think the most important improvements are: 1. to swap the teachpack menus for 2e and 1e 2. to increase the titles of all three panes so that it becomes clear what you are dealing with Eventually the pane for 1e should become something almost hidden but we are not there yet. -- Matthias p.s. And yes, it would be nice if the window had a title such as add teachpacks On Mar 23, 2013, at 5:49 PM, Sam Tobin-Hochstadt wrote: Opening up the Add Teachpack dialog presents the user with two lists of libraries, which overlap in exactly one case: image.ss. This makes it very easy for the user to choose the old image.ss library when working with HtDP2e. Further, there's no indication in DrRacket as to which one of these was chosen. I can think of a couple ways this could be improved: the HtDP2e prologue could be explicit about which pane of the dialog to look in, and the dialog itself could ask the user which book they're using. Also, it would be great if DrRacket said Teachpack: image.ss (from HtDP) in the language position. Or we could just hide the old teachpack. Sam PS: the Add Teachpack dialog has no title on my machine, or rather it's just titled DrRacket. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
On Apr 1, 2013, at 9:45 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I don't see why middle school students would have more trouble with `require` than with any other aspect of the system. I tend to agree with Sam on this one. I haven't taught 12-year-old middle school students, but if they can handle (ellipse 50 30 solid purple), surely they can handle a boilerplate (require picturing-programs) or (require 2htdp/image). And as Sam points out, even if we keep the Add Teachpack dialog, it could work by inserting a require into the code. Also, WeScheme just provides graphics libraries by default, which is another option we could consider. Bad idea; somebody might want to teach with his/her own version of the graphics libraries. (I was in this boat before we bundled picturing-programs.) Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Purpose of typed/racket/no-check
On 4/1/13 11:16 AM, Robby Findler wrote: You could change the ellipsis to Integer. :) Or no-check could bind ellipsis to some type. This would be useful for sketching types out in no-check and then refining them to actual types in TR. David Robby On Mon, Apr 1, 2013 at 8:23 AM, Eli Barzilay e...@barzilay.org mailto:e...@barzilay.org wrote: 20 minutes ago, Matthias Felleisen wrote: On Mar 31, 2013, at 9:32 PM, Sam Tobin-Hochstadt wrote: My expectation when using typed/racket/no-check is that I won't get any type errors. To me, the words no check mean just that: do not type-check the module. But I think it is okay to parse the types. I doubt people use this option when they wish to avoid a parse error in the type expressions. As a semi-random data point, I sometime use my no-check language (which is built on top of TR's) to show how things work in class without getting all the types right (or when there's some problem with the types). In these cases I sometime use bogus type declarations like (All (A B) ...), which IIUC wouldn't work anymore. It's just technically simpler and clearer to still use `:' instead of going back to comments. (But it's obviously a weak point.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Purpose of typed/racket/no-check
An hour and a half ago, David Van Horn wrote: On 4/1/13 11:16 AM, Robby Findler wrote: You could change the ellipsis to Integer. :) The time that I'd spend explaining why I wrote `Integer' makes the comment route more appealing... Or no-check could bind ellipsis to some type. This would be useful for sketching types out in no-check and then refining them to actual types in TR. Well, I used ... in the natural sense of some stuff. Having it bound to some type sounds cute, but definitely too much work than it's worth. (At least IMO.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
Two hours ago, Stephen Bloch wrote: I tend to agree with Sam on this one. I haven't taught 12-year-old middle school students, but if they can handle (ellipse 50 30 solid purple), surely they can handle a boilerplate (require picturing-programs) or (require 2htdp/image). It could be simplified into some new simplified `require' that is easier for kids -- like (use image). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
On Mon, Apr 1, 2013 at 9:49 AM, Stephen Bloch bl...@adelphi.edu wrote: On Apr 1, 2013, at 9:45 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I don't see why middle school students would have more trouble with `require` than with any other aspect of the system. I tend to agree with Sam on this one. I haven't taught 12-year-old middle school students, but if they can handle (ellipse 50 30 solid purple), surely they can handle a boilerplate (require picturing-programs) or (require 2htdp/image). And as Sam points out, even if we keep the Add Teachpack dialog, it could work by inserting a require into the code. Also, WeScheme just provides graphics libraries by default, which is another option we could consider. Bad idea; somebody might want to teach with his/her own version of the graphics libraries. (I was in this boat before we bundled picturing-programs.) But picturing-programs didn't have to change the existing image functions, right? It could either just give a new set or augment the existing set and still have worked for you? Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Add Teachpack dialog can be very confusing
On Apr 1, 2013, at 3:43 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Mon, Apr 1, 2013 at 9:49 AM, Stephen Bloch bl...@adelphi.edu wrote: Also, WeScheme just provides graphics libraries by default, which is another option we could consider. Bad idea; somebody might want to teach with his/her own version of the graphics libraries. (I was in this boat before we bundled picturing-programs.) But picturing-programs didn't have to change the existing image functions, right? It could either just give a new set or augment the existing set and still have worked for you? There were a few that I tweaked while keeping the names the same. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
