Re: [racket-dev] a ftp gui client demo, anyone interest?
We had a freshman two years back who implemented an ftp server. I think he (and others like him) would have enjoyed a tutorial on ftp (server and client). It may belong into the systems tutorial -- Matthias On Dec 16, 2012, at 10:19 PM, Chen Xiao wrote: Hi, I use the new ftp client api(not release yet) to implement a ftp gui client. It demos connect, directory list, download, upload, download(upload) progressing bar. I think i can be a short tutorial to the usage of the ftp client api. Anyone interest? Can I add this into the tutorial somewhere? 屏幕快照 2012-12-17 上午10.31.43.png_ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On Dec 17, 2012, at 12:59 AM, Neil Toronto wrote: On 12/16/2012 06:41 PM, Eli Barzilay wrote: 10 minutes ago, Neil Toronto wrote: I think I'd rather have a convention in Typed Racket that (require foo) imports `foo/typed' when it exists. +14. I think it came up in the past, but I don't know why it wasn't done... No consensus? That happens a lot. It has serious performance implications for untyped modules that require plot -- and these should not be hidden. I know we hide bigint operations but is this an excuse to hide such problems pervasively? W/o support? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On 2012-12-17 09:54:36 -0500, Matthias Felleisen wrote: It has serious performance implications for untyped modules that require plot -- and these should not be hidden. My understanding (possibly wrong), was that the typed submodule would only be required from another typed module in this proposal. That means the performance hit from contracts is only for TR programs. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] URL escaping: question for web experts
For many people there is a constant source of annoyance when you copy+paste doc URLs into a markdown context as with stackoverflow and others. The problem is that these URLs have parens in them and at least in Chrome, the copied URL still has them -- and because markdown texts use parens for URLs [text](url) they get confused which means that you have to manually replace parens with %28 and %29. Danny submitted a pull request that eventually got changed by Matthew into a new parameter that controls which characters get encoded by `net/uri-codec', so it can escape these too. The result on Chrome is that the copied URL has the escapes instead of parens, and clicking such a URL makes the copy-able address have the escapes too. The actuall page that is displayed is still the same one, of course, it's just weird that Chrome has a certain context where the original URL string is preserved as is. (It even considered the escaped URL as one that I didn't visit, even though I visited the one with the unescaped parens.) In any case, given all of this I thought that maybe the default mode could do the extra escaping -- it seems to me that there is no damage with doing that, since in theory every character could be escaped anyway. There's a minor overhead of a few extra characters, but there's the above benefit of doing it (which might be a temporary thing for all I know). Neither Matthew nor I feel confident enough to have this encoding be the default without consulting some potential web standard gurus. So? -- ((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] a ftp gui client demo, anyone interest?
I love this idea, since it also (at least impliticly) demonstrates how to work with Racket's GUI layer, which could also be useful to new users. Matthias Felleisen matth...@ccs.neu.edu writes: We had a freshman two years back who implemented an ftp server. I think he (and others like him) would have enjoyed a tutorial on ftp (server and client). It may belong into the systems tutorial -- Matthias On Dec 16, 2012, at 10:19 PM, Chen Xiao wrote: Hi, I use the new ftp client api(not release yet) to implement a ftp gui client. It demos connect, directory list, download, upload, download(upload) progressing bar. I think i can be a short tutorial to the usage of the ftp client api. Anyone interest? Can I add this into the tutorial somewhere? 屏幕快照 2012-12-17 上午10.31.43.png_ 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] Embedding racket in vim
Eric, I incorporated you changes into http://code.google.com/r/sergeykhorev-vim-mzscheme/source. Can you try it on Mac? Bram, Please let me know what I should include in the distribution. The patch was missing changes to configure.in. I will send you a cumulative patch once it is tested. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] URL escaping: question for web experts
Although I'm hardly a web expert, I think net/uri-codec is currently a little confusing. I get the impression that it was originally written prior to 2005, because the detailed introduction talks only about RFCs 1738 and 2396.[1] It looks like perhaps functions such as uri-path-segment-encode were added at a later date, to support RFC 3986. Although these functions' docs tersely link to RFC 3986, the overall net/uri-codec introduction wasn't revised accordingly, nor is there a simple explanation like these also encode #\( #\) (As a result, I actually ended up writing my own variation because I overlooked them.) Aside from the history of the documentation and organization, another point is the treatment of +, which the docs say intentionally doesn't follow RFC 2396, but don't really explain why. (One of my earliest experiments with Racket was a simple web crawler, and this #\+ - #\space translation caused difficulties (although it's possible I was confused in other ways).) Wikipedia (usual caveats apply) says RFC 3986 is the the current standard since 2005.[2] I almost wonder if there should be a brand-new module that implements RFC 3986 strictly. (Either just that, or, any options/parameters default to 3986). With the current net/uri-codec deprecated but preserved for backward compatibility. I wonder if that would be best because the functions and documentation may already be confusing. And this is a topic where it's easy for people to get confused to begin with and choose the wrong function. [1]: http://docs.racket-lang.org/net/uri-codec.html [2]: http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_in_a_URI On Mon, Dec 17, 2012 at 9:59 AM, Eli Barzilay e...@barzilay.org wrote: For many people there is a constant source of annoyance when you copy+paste doc URLs into a markdown context as with stackoverflow and others. The problem is that these URLs have parens in them and at least in Chrome, the copied URL still has them -- and because markdown texts use parens for URLs [text](url) they get confused which means that you have to manually replace parens with %28 and %29. Danny submitted a pull request that eventually got changed by Matthew into a new parameter that controls which characters get encoded by `net/uri-codec', so it can escape these too. The result on Chrome is that the copied URL has the escapes instead of parens, and clicking such a URL makes the copy-able address have the escapes too. The actuall page that is displayed is still the same one, of course, it's just weird that Chrome has a certain context where the original URL string is preserved as is. (It even considered the escaped URL as one that I didn't visit, even though I visited the one with the unescaped parens.) In any case, given all of this I thought that maybe the default mode could do the extra escaping -- it seems to me that there is no damage with doing that, since in theory every character could be escaped anyway. There's a minor overhead of a few extra characters, but there's the above benefit of doing it (which might be a temporary thing for all I know). Neither Matthew nor I feel confident enough to have this encoding be the default without consulting some potential web standard gurus. So? -- ((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
Re: [racket-dev] URL escaping: question for web experts
p.s. Also the current docs[1] say this in the second paragraph: The URI encoding uses allows a few characters to be represented as-is: a through z, A through Z, 0-9, -, _, ., !, ~, *, ', ( and ). But this in the final sentence: In additon, since there appear to be some brain-dead decoders on the web, the library also encodes !, ~, ', (, and ) using their hex representation, which is the same choice as made by the Java’s URLEncoder. Which seems to be contradictory with respect to !, ~, ', ( and ). [1]: http://docs.racket-lang.org/net/uri-codec.html On Mon, Dec 17, 2012 at 11:55 AM, Greg Hendershott greghendersh...@gmail.com wrote: Although I'm hardly a web expert, I think net/uri-codec is currently a little confusing. I get the impression that it was originally written prior to 2005, because the detailed introduction talks only about RFCs 1738 and 2396.[1] It looks like perhaps functions such as uri-path-segment-encode were added at a later date, to support RFC 3986. Although these functions' docs tersely link to RFC 3986, the overall net/uri-codec introduction wasn't revised accordingly, nor is there a simple explanation like these also encode #\( #\) (As a result, I actually ended up writing my own variation because I overlooked them.) Aside from the history of the documentation and organization, another point is the treatment of +, which the docs say intentionally doesn't follow RFC 2396, but don't really explain why. (One of my earliest experiments with Racket was a simple web crawler, and this #\+ - #\space translation caused difficulties (although it's possible I was confused in other ways).) Wikipedia (usual caveats apply) says RFC 3986 is the the current standard since 2005.[2] I almost wonder if there should be a brand-new module that implements RFC 3986 strictly. (Either just that, or, any options/parameters default to 3986). With the current net/uri-codec deprecated but preserved for backward compatibility. I wonder if that would be best because the functions and documentation may already be confusing. And this is a topic where it's easy for people to get confused to begin with and choose the wrong function. [1]: http://docs.racket-lang.org/net/uri-codec.html [2]: http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_in_a_URI On Mon, Dec 17, 2012 at 9:59 AM, Eli Barzilay e...@barzilay.org wrote: For many people there is a constant source of annoyance when you copy+paste doc URLs into a markdown context as with stackoverflow and others. The problem is that these URLs have parens in them and at least in Chrome, the copied URL still has them -- and because markdown texts use parens for URLs [text](url) they get confused which means that you have to manually replace parens with %28 and %29. Danny submitted a pull request that eventually got changed by Matthew into a new parameter that controls which characters get encoded by `net/uri-codec', so it can escape these too. The result on Chrome is that the copied URL has the escapes instead of parens, and clicking such a URL makes the copy-able address have the escapes too. The actuall page that is displayed is still the same one, of course, it's just weird that Chrome has a certain context where the original URL string is preserved as is. (It even considered the escaped URL as one that I didn't visit, even though I visited the one with the unescaped parens.) In any case, given all of this I thought that maybe the default mode could do the extra escaping -- it seems to me that there is no damage with doing that, since in theory every character could be escaped anyway. There's a minor overhead of a few extra characters, but there's the above benefit of doing it (which might be a temporary thing for all I know). Neither Matthew nor I feel confident enough to have this encoding be the default without consulting some potential web standard gurus. So? -- ((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
Re: [racket-dev] Typed versions of untyped collections
On Mon, Dec 17, 2012 at 12:59 AM, Neil Toronto neil.toro...@gmail.com wrote: On 12/16/2012 06:41 PM, Eli Barzilay wrote: 10 minutes ago, Neil Toronto wrote: I think I'd rather have a convention in Typed Racket that (require foo) imports `foo/typed' when it exists. +14. I think it came up in the past, but I don't know why it wasn't done... It hasn't been done because I don't think it's a good idea. There are a couple reasons for this. First, I really don't want to add a search path to the module resolution algorithm. Second, there's no actual good way to tell if a module is typed, esp. without loading the module first. That's in addition to the costs Matthias mentions. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
20 minutes ago, Sam Tobin-Hochstadt wrote: On Mon, Dec 17, 2012 at 12:59 AM, Neil Toronto neil.toro...@gmail.com wrote: On 12/16/2012 06:41 PM, Eli Barzilay wrote: 10 minutes ago, Neil Toronto wrote: I think I'd rather have a convention in Typed Racket that (require foo) imports `foo/typed' when it exists. +14. I think it came up in the past, but I don't know why it wasn't done... It hasn't been done because I don't think it's a good idea. (Ah, that sounds familiar...) There are a couple reasons for this. First, I really don't want to add a search path to the module resolution algorithm. Second, there's no actual good way to tell if a module is typed, esp. without loading the module first. There's no need for that if you grab the */typed.rkt namespace, or with submodules (I'm guessing). That's in addition to the costs Matthias mentions. I think that the costs that he talked about were the T-TR contracts, which are there anyway if people use the same code for both. BTW, a similar alternative would be a TR language that arranges for the same code to be put in a typed and an untyped submodules, so you can use both variants. It should work well given TR's goal of being as compatible with R as possible. -- ((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] URL escaping: question for web experts
No guru here, but my experience has been that every url encoder is slightly different - I don't think there's a broad consensus on edge cases. I'd say go for it. On 12/17/2012 06:59 AM, Eli Barzilay wrote: For many people there is a constant source of annoyance when you copy+paste doc URLs into a markdown context as with stackoverflow and others. The problem is that these URLs have parens in them and at least in Chrome, the copied URL still has them -- and because markdown texts use parens for URLs [text](url) they get confused which means that you have to manually replace parens with %28 and %29. Danny submitted a pull request that eventually got changed by Matthew into a new parameter that controls which characters get encoded by `net/uri-codec', so it can escape these too. The result on Chrome is that the copied URL has the escapes instead of parens, and clicking such a URL makes the copy-able address have the escapes too. The actuall page that is displayed is still the same one, of course, it's just weird that Chrome has a certain context where the original URL string is preserved as is. (It even considered the escaped URL as one that I didn't visit, even though I visited the one with the unescaped parens.) In any case, given all of this I thought that maybe the default mode could do the extra escaping -- it seems to me that there is no damage with doing that, since in theory every character could be escaped anyway. There's a minor overhead of a few extra characters, but there's the above benefit of doing it (which might be a temporary thing for all I know). Neither Matthew nor I feel confident enough to have this encoding be the default without consulting some potential web standard gurus. So? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] URL escaping: question for web experts
Just now, David Vanderson wrote: No guru here, but my experience has been that every url encoder is slightly different - I don't think there's a broad consensus on edge cases. I'd say go for it. The problem is not just being different from others, it's the possibility of old code breaking... -- ((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] [plt] Push #25911: master branch updated
At Mon, 17 Dec 2012 15:00:04 -0500, stamo...@racket-lang.org wrote: b715a6f Vincent St-Amour stamo...@racket-lang.org 2012-12-14 11:39 : | Add define-inline. | | Drop-in replacement for define that guarantees inlining. : M collects/meta/props | 2 ++ A collects/unstable/inline.rkt A collects/unstable/scribblings/inline.scrbl M collects/unstable/scribblings/unstable.scrbl | 1 + I'm not sure where this should go, so I put it in `unstable' for now. It's related to `begin-encourage-inline' from `racket/performance-hint' but since `define-inline' depends on `syntax/parse', I'm hesitant to put it there. The new Optimization Coach will recommend using it instead of `define' in some cases, so maybe it should be provided by OC? It's useful beyond OC, though, so that doesn't feel like the right place. Suggestions? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. If the convention how the names get adjusted and whatnot is just documented, then every library writer can provide both versions. And yes, there are details I'm glossing over here, but just doing nothing isn't helping. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25911: master branch updated
On Dec 17, 2012, at 3:12 PM, Vincent St-Amour wrote: It's related to `begin-encourage-inline' from `racket/performance-hint' but since `define-inline' depends on `syntax/parse', I'm hesitant to put it there. It sounds like this is where it belongs. The new Optimization Coach will recommend using it instead of `define' in some cases, so maybe it should be provided by OC? It's useful beyond OC, though, so that doesn't feel like the right place. Wrong place. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] egal?
Short message: is there any chance of getting egal and egal hashes any time soon? Longer message: I have a situation where I key my hashes with immutable structs, but something they contain has a box that later is updated and never changed. I'd really like for the struct value before the set-box! to be keyed to and positively compare to the value after this set-box! happens. Otherwise I have to do something abstraction-breaking to separate these boxes from the structures which would likely introduce more overhead (yet another hash lookup). I'm going to look into just hacking egal in myself, but want to know what the other devs know about this. Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
When Neil created his library, I proposed that he create one piece of source code and 'generate' both the typed and untyped module from it. If we foresee this kind of library to become more common, we should probably provide the capability as an abstraction from TR. -- Matthias On Dec 17, 2012, at 3:27 PM, Robby Findler wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. If the convention how the names get adjusted and whatnot is just documented, then every library writer can provide both versions. And yes, there are details I'm glossing over here, but just doing nothing isn't helping. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
I think TR does have some of this facility already. Robby On Mon, Dec 17, 2012 at 2:41 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: When Neil created his library, I proposed that he create one piece of source code and 'generate' both the typed and untyped module from it. If we foresee this kind of library to become more common, we should probably provide the capability as an abstraction from TR. -- Matthias On Dec 17, 2012, at 3:27 PM, Robby Findler wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. If the convention how the names get adjusted and whatnot is just documented, then every library writer can provide both versions. And yes, there are details I'm glossing over here, but just doing nothing isn't helping. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] egal?
It sounds like an easier solution would be to switch from boxes to a mutable struct with one field that overrides equal? and hash-code. Ryan On 12/17/2012 03:38 PM, J. Ian Johnson wrote: Short message: is there any chance of getting egal and egal hashes any time soon? Longer message: I have a situation where I key my hashes with immutable structs, but something they contain has a box that later is updated and never changed. I'd really like for the struct value before the set-box! to be keyed to and positively compare to the value after this set-box! happens. Otherwise I have to do something abstraction-breaking to separate these boxes from the structures which would likely introduce more overhead (yet another hash lookup). I'm going to look into just hacking egal in myself, but want to know what the other devs know about this. Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
I don't think so. What it has is a declaration that says don't check the types. What I am proposing is -- check the types -- and generate an untyped version from this file. #lang typed/racket #:check-and-generate untyped-foo.rkt (: x Integer) (define x 10) would generate #lang racket (define x 10) IF and ONLY IF the original file type checks. The original file could also be used as a TR library. Perhaps the API isn't quite right. On Dec 17, 2012, at 3:49 PM, Robby Findler wrote: I think TR does have some of this facility already. Robby On Mon, Dec 17, 2012 at 2:41 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: When Neil created his library, I proposed that he create one piece of source code and 'generate' both the typed and untyped module from it. If we foresee this kind of library to become more common, we should probably provide the capability as an abstraction from TR. -- Matthias On Dec 17, 2012, at 3:27 PM, Robby Findler wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. If the convention how the names get adjusted and whatnot is just documented, then every library writer can provide both versions. And yes, there are details I'm glossing over here, but just doing nothing isn't helping. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
At Mon, 17 Dec 2012 15:51:38 -0500, Sam Tobin-Hochstadt wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. FWIW, our current module-loading infrastructure is better adapted to a search for `(submod typed racket/list)' in place of `racket/list', instead of `racket/list/typed'. That is, submodule paths are intended to play nicer with a search, and that intent is encoded in rules for layers of module and load handlers. (I don't know whether the search is a good idea.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
It is getting exactly the same file as R, except there is a special file in the TR code that gives types to some bindings (all of the ones from racket). Your new module's bindings are not in this file. https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
For the purposes of this conversation, I don't think it is fair to stop after the comma in your sentence, Eric. :) Robby On Mon, Dec 17, 2012 at 3:29 PM, Eric Dobson eric.n.dob...@gmail.comwrote: It is getting exactly the same file as R, except there is a special file in the TR code that gives types to some bindings (all of the ones from racket). Your new module's bindings are not in this file. https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] bit-vectors and serialization
On 12/17/2012 04:30 AM, Jens Axel Søgaard wrote: 2012/12/17 Ryan Culpepper r...@cs.utah.edu: I'd like to make bit-vectors serializable so I can replace sql-bits with them. I'll deprecate the current sql-bits names but keep them around for a while. The issue is that bit-vectors are implemented using fxvectors, which are serializable, but simply serializing them will presumably cause errors if a bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit machine or vice versa. One solution would be to use bytes instead of fxvectors. The performance is about the same as far as I could tell using the sieve benchmark. Another option is to declare that serialization across word sizes doesn't work for bit vectors. Any opinions? The sieve-benchmark works on individual bits, so it makes sense that the performance is about the same. What happens for operations that work on words (e.g. the popcount operation)? My intuition is that these operations will be slower. True, popcount takes about three times as long as it used to. With a few additional changes, popcount on a million-bit bit-vector takes 1.1 ms using bytes, as opposed to 0.35 ms using fxvectors. (Tested on a 64-bit machine.) Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
My understanding is that -- Neil created a single file P, I believe it is typed -- he tells you to load plot/typed/ for the typed version -- he tells you to load plot/ for the untyped version Somewhere in this arrangement a call in some untyped client to a function f from P will cross a line. If this is wrong, I'd like to know where it goes wrong. - I like the submodule idea a lot. On Dec 17, 2012, at 4:16 PM, Robby Findler wrote: I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On 12/17/2012 02:44 PM, Matthias Felleisen wrote: My understanding is that -- Neil created a single file P, I believe it is typed -- he tells you to load plot/typed/ for the typed version -- he tells you to load plot/ for the untyped version Somewhere in this arrangement a call in some untyped client to a function f from P will cross a line. If this is wrong, I'd like to know where it goes wrong. You're thinking of `math/array', which is written in Typed Racket. There *is* a big performance problem with arrays in untyped code, because arrays are basically higher-order functions. Getting elements from arrays that cross the contract barrier is expensive. `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached. I like the submodule idea a lot. Cool. I'd like to know how much work it would take to implement it. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On Dec 17, 2012, at 5:43 PM, Neil Toronto wrote: On 12/17/2012 02:44 PM, Matthias Felleisen wrote: My understanding is that -- Neil created a single file P, I believe it is typed -- he tells you to load plot/typed/ for the typed version -- he tells you to load plot/ for the untyped version Somewhere in this arrangement a call in some untyped client to a function f from P will cross a line. If this is wrong, I'd like to know where it goes wrong. You're thinking of `math/array', which is written in Typed Racket. There *is* a big performance problem with arrays in untyped code, because arrays are basically higher-order functions. Getting elements from arrays that cross the contract barrier is expensive. Okay. `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached. I don't understand this last part at all. You have -- an untyped file M -- a typed file T that imports M and re-exports everything from there with types How can it possibly be the case that a client C imports T and does NOT pay for the contracts that T's types impose on the call chain? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On 12/17/2012 03:55 PM, Matthias Felleisen wrote: On Dec 17, 2012, at 5:43 PM, Neil Toronto wrote: On 12/17/2012 02:44 PM, Matthias Felleisen wrote: My understanding is that -- Neil created a single file P, I believe it is typed -- he tells you to load plot/typed/ for the typed version -- he tells you to load plot/ for the untyped version Somewhere in this arrangement a call in some untyped client to a function f from P will cross a line. If this is wrong, I'd like to know where it goes wrong. You're thinking of `math/array', which is written in Typed Racket. There *is* a big performance problem with arrays in untyped code, because arrays are basically higher-order functions. Getting elements from arrays that cross the contract barrier is expensive. Okay. `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached. I don't understand this last part at all. You have -- an untyped file M -- a typed file T that imports M and re-exports everything from there with types How can it possibly be the case that a client C imports T and does NOT pay for the contracts that T's types impose on the call chain? That would only happen if client C is untyped. I wouldn't expect an untyped client to (require plot/typed), but I suppose it could happen. So I suppose we have another, but rather unlikely, reason to have TR's `require' check for a `typed' submodule. Currently, if some macro wants to expand to (require plot) and a few plots, it actually should expand to (require plot/typed) and a few plots in case it's used in typed code. That results in a double layer of contract checks when used in untyped code. If plots don't make much sense here, substitute your favorite untyped library that might end up with an additional typed interface. Here's another reason: TR currently does magical things that user code can't do. I think one of the long-term goals of TR should be to turn such special cases into general cases. One of them is allowing TR programs to use (require racket/list) to import typed identifiers. We should be able to do that with anything that provides a typed interface. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On Dec 17, 2012, at 6:10 PM, Neil Toronto wrote: `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached. I don't understand this last part at all. You have -- an untyped file M -- a typed file T that imports M and re-exports everything from there with types How can it possibly be the case that a client C imports T and does NOT pay for the contracts that T's types impose on the call chain? That would only happen if client C is untyped. I wouldn't expect an untyped client to (require plot/typed), but I suppose it could happen. Wait. This is the line I don't understand: C is TYPED. It requires T. T is TYPED. It requires M. M is UNTYPED. If c in C calls t in T, this first call does not add any overhead. OK. But t is really m from M obtained with a require/typed. [Alternatively, it is redefinition that calls such a function.] It is this call from t to m that imposes the overhead. Why are you saying that There's no performance problem with typed plots at all? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
On 12/17/2012 04:32 PM, Matthias Felleisen wrote: On Dec 17, 2012, at 6:10 PM, Neil Toronto wrote: `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached. I don't understand this last part at all. You have -- an untyped file M -- a typed file T that imports M and re-exports everything from there with types How can it possibly be the case that a client C imports T and does NOT pay for the contracts that T's types impose on the call chain? That would only happen if client C is untyped. I wouldn't expect an untyped client to (require plot/typed), but I suppose it could happen. Wait. This is the line I don't understand: C is TYPED. It requires T. T is TYPED. It requires M. M is UNTYPED. If c in C calls t in T, this first call does not add any overhead. OK. But t is really m from M obtained with a require/typed. [Alternatively, it is redefinition that calls such a function.] It is this call from t to m that imposes the overhead. Why are you saying that There's no performance problem with typed plots at all? Oh! Oh, right... I totally forgot that `require/typed' wraps things in contracts. Duh. Yes. So plotting in Typed Racket goes through two contract barriers. It's a small performance hit compared to the rest of the rendering pipeline. But it's a performance hit. We can carry on now. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
Okay. I propose we figure out how to allow people programming in Typed Racket, and deploy two copies of the code without performance overhead for either T or U code. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] URL escaping: question for web experts
Not an expert, don't even do much in this area much these days. Historically, I have seen a number of REST URL API patterns, more often then not (when these things were less tepid than they are now) in the Semantic Web area (e.g. MS OData) where parens, which as I recall is allowed by the RFC, are lifted to distinguished delimiters in the URI template. But REST, HTTP APIs. et al have seen their heyday and shall remain Web-centric remnants. 5 years from now I doubt any newly minted mobile device centric TCP/IP Internet APIs will be based on REST, HTTP and URIs. But my crystal ball tends to be foggier than even most. Frankly I doubt you would break anything in the Racket ecosystem if you did it. Personally, I'd not do it solely on the merit of copy/paste easing. I have felt the pain in the opposite direction where a browser or tool has somewhat arbitrarily gone out of the way to escape parens when I'm trying to cut/paste and I've had to restore them. So FWIW, -1. On Mon, Dec 17, 2012 at 2:56 PM, Eli Barzilay e...@barzilay.org wrote: Just now, David Vanderson wrote: No guru here, but my experience has been that every url encoder is slightly different - I don't think there's a broad consensus on edge cases. I'd say go for it. The problem is not just being different from others, it's the possibility of old code breaking... -- ((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
Re: [racket-dev] Typed versions of untyped collections
That is what I meant to be asking for. I put too much of what I guess would be a good approach into my messages, tho. Sorry about that. Robby On Mon, Dec 17, 2012 at 5:44 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: Okay. I propose we figure out how to allow people programming in Typed Racket, and deploy two copies of the code without performance overhead for either T or U code. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25914: master branch updated
I'm not sure about this change. If I pass in a buggy function, I'm not sure I'd want the errors to get swallowed. How about making the plot but putting a red thing on it (and maybe showing the error text on mouseover)? Or maybe making this optional behavior? Robby On Mon, Dec 17, 2012 at 6:02 PM, ntoro...@racket-lang.org wrote: ntoronto has updated `master' from d120286f89 to 2657d8f96b. http://git.racket-lang.org/plt/d120286f89..2657d8f96b =[ One Commit ]= Directory summary: 92.4% collects/plot/common/ 7.5% collects/plot/tests/ ~~ 2657d8f Neil Toronto ntoro...@racket-lang.org 2012-12-17 16:58 : | Plots whose functions raise errors now have an empty spot instead of | failing : M collects/plot/common/sample.rkt | 9 ++--- M collects/plot/tests/plot2d-tests.rkt | 2 ++ =[ Overall Diff ]=== collects/plot/common/sample.rkt ~~~ --- OLD/collects/plot/common/sample.rkt +++ NEW/collects/plot/common/sample.rkt @@ -134,7 +134,8 @@ (defproc (make-function-sampler [transform-thnk (- axis-transform/c)] ) (- (real? . - . real?) ivl? sampler/c) - (λ (f inner-ivl) + (λ (g inner-ivl) +(define f (λ (x) (with-handlers ([exn:fail? (λ (_) +nan.0)]) (g x (define memo (make-hash)) (λ (outer-ivl num) (define tx (transform-thnk)) @@ -155,7 +156,8 @@ ) (- (real? real? . - . real?) (vector/c ivl? ivl?) 2d-sampler/c) - (λ (f inner-rect) + (λ (g inner-rect) +(define f (λ (x y) (with-handlers ([exn:fail? (λ (_) +nan.0)]) (g x y (define memo (make-hash)) (λ (outer-rect nums) (define tx (transform-x-thnk)) @@ -186,7 +188,8 @@ ) (- (real? real? real? . - . real?) (vector/c ivl? ivl? ivl?) 3d-sampler/c) - (λ (f inner-rect) + (λ (g inner-rect) +(define f (λ (x y z) (with-handlers ([exn:fail? (λ (_) +nan.0)]) (g x y z (define memo (make-hash)) (λ (outer-rect nums) (define tx (transform-x-thnk)) collects/plot/tests/plot2d-tests.rkt --- OLD/collects/plot/tests/plot2d-tests.rkt +++ NEW/collects/plot/tests/plot2d-tests.rkt @@ -4,6 +4,8 @@ ;(plot-new-window? #t) +(plot (function / -249 250)) + (time (define xs (build-list 1 (λ _ (random (plot (density xs 1/2))) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
I, perhaps unsurprisingly, disagree. If `listt.rkt` re-provided everything from `list.rkt`, then it would continue to work. These decisions are made entirely on the basis of the particular identifiers involved -- which module is loaded has nothing to do with it. But regardless of exactly how types are declared for the builtin modules (this could be done with submodules instead, potentially, in which case the copying would work), right now TR does not translate requires at all, and I'd like to keep it that way On Mon, Dec 17, 2012 at 4:30 PM, Robby Findler ro...@eecs.northwestern.edu wrote: For the purposes of this conversation, I don't think it is fair to stop after the comma in your sentence, Eric. :) Robby On Mon, Dec 17, 2012 at 3:29 PM, Eric Dobson eric.n.dob...@gmail.com wrote: It is getting exactly the same file as R, except there is a special file in the TR code that gives types to some bindings (all of the ones from racket). Your new module's bindings are not in this file. https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed versions of untyped collections
Fine. I give up. Robby On Mon, Dec 17, 2012 at 7:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: I, perhaps unsurprisingly, disagree. If `listt.rkt` re-provided everything from `list.rkt`, then it would continue to work. These decisions are made entirely on the basis of the particular identifiers involved -- which module is loaded has nothing to do with it. But regardless of exactly how types are declared for the builtin modules (this could be done with submodules instead, potentially, in which case the copying would work), right now TR does not translate requires at all, and I'd like to keep it that way On Mon, Dec 17, 2012 at 4:30 PM, Robby Findler ro...@eecs.northwestern.edu wrote: For the purposes of this conversation, I don't think it is fair to stop after the comma in your sentence, Eric. :) Robby On Mon, Dec 17, 2012 at 3:29 PM, Eric Dobson eric.n.dob...@gmail.com wrote: It is getting exactly the same file as R, except there is a special file in the TR code that gives types to some bindings (all of the ones from racket). Your new module's bindings are not in this file. https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I don't understand Matthias's performance comments. If, in TR (require plot) actually gives me a typed version of the library and in R (require plot) gives me the untyped version of the library, then I am avoiding the performance the untyped/typed performance overhead properly. If, on the other hand, if I have to commit that (require plot) gives me either the untyped or the typed version, then I have to suffer the performance overhead when I require it from the wrong context. Neil's original complaint also has validity, I think: if he provides a plot/typed today, and then later ports plot so it is typed, then he has to keep this extra thing around for what appears to not be a very good reason. And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse. And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation. For example, the docs for 'require' do not explain why I can make a copy of list.rkt (in the racket collection), call the copy listt.rkt and have that copy not work, but the original one does. Clearly TR is not just get[ting] *exactly* the same file as in R, so I think Sam's comments are off base. Robby On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've long thought something along these lines is a good idea, but perhaps what I think is a good idea isn't what Matthias and Sam think is the bad idea. I think that it makes sense for 'require' in typed-racket to look in a different place than 'require' in untyped racket looks so that one can write the same require spec (in both the docs and the code) and have two versions of the same library, one that is typed and one that isn't typed. Then, then library writer, if they choose, can decide who pays what for going (or not) across the boundary between typed and untyped. (Or maybe submodules would be better.) I think this is exactly what Eli was suggesting, and what I think is a bad idea. I think this is already happening in TR anyways, when I write (require racket/list) I don't get the same file being loaded when that is in a TR program as when it is in a R program. You get *exactly* the same file as in R. I think that (a) this is a valuable invariant and (b) the mechanisms for violating this invariant are all very worrying. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] supplying typed and untyped entry points, take 2
Begin forwarded message: From: Matthias Felleisen matth...@ccs.neu.edu Subject: Re: [racket-dev] Typed versions of untyped collections Date: December 17, 2012 6:44:19 PM EST To: Neil Toronto neil.toro...@gmail.com Cc: dev@racket-lang.org Okay. I propose we figure out how to allow people programming in Typed Racket, and deploy two copies of the code without performance overhead for either T or U code. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25914: master branch updated
On 12/17/2012 05:48 PM, Robby Findler wrote: I'm not sure about this change. If I pass in a buggy function, I'm not sure I'd want the errors to get swallowed. The errors are almost always division by zero or some similar mathematical domain error, because plotted functions get sent exact rational numbers. Also, it's usually obvious on the plot where there's an error. In 3D and contour plots in particular, the holes are gaping. How about making the plot but putting a red thing on it (and maybe showing the error text on mouseover)? That's not a bad idea. I'll think about how to implement it. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] supplying typed and untyped entry points, take 2
IIRC, one of your ideas was to expand module code to a typed and an untyped submodule, and have them provide the same identifiers. Somehow - doesn't matter exactly for now - untyped clients would get the untyped identifiers, and typed clients would get the typed identifiers. I've had some experience doing something similar with macros. A good example is the `in-array' macro, defined in math/private/array/array-sequence.rkt. Here's part of the expansion of (in-array arr-expr): (plet: (A) ([arr : (Array A) arr-expr]) (cond [(array? arr) (define ds (array-shape arr)) (define dims (vector-length ds)) (define size (array-size arr)) (define proc (unsafe-array-proc arr)) (define: js : Indexes (make-vector dims 0)) (values ds size dims js proc)] [else (raise-argument-error 'in-array Array arr)])) It's kind of annoying to have to keep in mind that the macro will be expanded in both typed and untyped contexts. In this case - and this is pretty typical - the expanded code has to ensure that it gets an array in two different ways. One is (plet: (A) ([arr : (Array A) arr-expr]) ...) for Typed Racket. The other is (cond [(array? arr) ...] [else ...]) for untyped Racket. One sort of nice thing is that TR's optimizer erases the `else' branch. I don't think it can erase the expression (array? arr), though. Also, the type annotations mean nothing in untyped Racket, so it's kind of like they get erased. I could see writing a few modules like this, especially with help from some good macros. The thing I worry about most is that a struct type would have two different definitions, typed and untyped, which would be different struct types at run time. In particular, an array created in a Typed Racket client couldn't be sent to an array-accepting function defined in an untyped client. That seems like a deal-breaker, and I can't think of an easy way around it. Neil ⊥ On 12/17/2012 06:34 PM, Matthias Felleisen wrote: Begin forwarded message: From: Matthias Felleisen matth...@ccs.neu.edu Subject: Re: [racket-dev] Typed versions of untyped collections Date: December 17, 2012 6:44:19 PM EST To: Neil Toronto neil.toro...@gmail.com Cc: dev@racket-lang.org Okay. I propose we figure out how to allow people programming in Typed Racket, and deploy two copies of the code without performance overhead for either T or U code. _ 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
