Re: [racket-dev] Revision to the Language Dialog
Matthias Felleisen wrote at 11/05/2012 10:14 PM: * racket/base (for scripting) * racket (for programming) After thinking about it, I think I see what you mean with the distinction between ``for scripting'' and ``for programming''. But I think this might be confusing. (Explanation... I have been thinking of it the other way around: #lang racket is what you use when you want to just start typing and have everything available and type less text, in a scripting-language kind of way, and #lang racket/base is what one uses when putting a little more care into engineering, and doesn't mind the extra thinking and text. For example, when making a reusable PLaneT package, I think it's good practice to go to the extra effort to use #lang racket/base instead of #lang racket; otherwise, you doom all users of your package to pull in all of #lang racket, which they might have engineering reasons not to do. But I guess you were speaking only of process load times -- that people would use racket/base so that standalone ``scripting'' programs would load quicker from the command line -- not about a quick-scripting nature of the programming activity?) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] My experience with Typed Racket
I've published a blog post about Typed Racket that I've been holding on to for a while. Mainly I intended it as feedback for Sam about what areas of TR I think can be improved, though it does provide a sort of tour through lots of Typed Racket features, so it should be readable by anyone with familiarity with Racket. http://unknownparallel.wordpress.com/2012/11/05/my-experience-with-typed-racket/ If I've made any errors, please let me know and I will correct them posthaste. -- Dan Burton _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] My experience with Typed Racket
Thanks for the feedback. You labeled the blog my experience with typed racket but you focus on the negative points. Perhaps you want to add , the Negative Parts to the title because your introduction makes it clear that you find a few good things. -- Matthias On Nov 5, 2012, at 5:46 PM, Dan Burton wrote: I've published a blog post about Typed Racket that I've been holding on to for a while. Mainly I intended it as feedback for Sam about what areas of TR I think can be improved, though it does provide a sort of tour through lots of Typed Racket features, so it should be readable by anyone with familiarity with Racket. http://unknownparallel.wordpress.com/2012/11/05/my-experience-with-typed-racket/ If I've made any errors, please let me know and I will correct them posthaste. -- Dan Burton _ Racket Developers list: http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Okay, thanks for the feedback. I've pushed a change that mostly takes the suggestions, except no blue and instead of the parentheticals, I've linked to the docs. (I don't like how the links don't line up vertically so I'll fix that unless the whole thing is dumped, depending on what people say here.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Well, I can't say that I'm excited about the prospect of going back to that dialog. My goal is to move towards no language dialog at all eventually and that change would not be a step in that direction. While we wait for others' opinions, I've pushed something that makes the ellipsis clickable, at least. On Tue, Nov 6, 2012 at 11:04 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Matthias Felleisen wrote: I second Sam's suggestions. -- I would use The Racket Language for the first line of the first +117 (I see it in the new dialog, but looks like the language still has the long name elsewhere.) I agree with Robby that *SLs probably have to reject (module ...) expressions EXCEPT that I don't see how they can get hold of the information that the programmer wrote down (other than guessing from the second position in the module expression but that sounds bad). I think that it's fine for drr to spit an appropriate error (maybe even with a shortcut click ok to switch to #lang button) if the definitions text starts with a #lang. It's only stealing the ability for the non-#lang languages to use #lang for something else, but none of them are doing it now, and since it's something that should eventually disappear there shouldn't be any new ones (or worse, new ones that use it). Also, the thing that sticks out to me (still) is the poor-looking UI. It's using a radio button selection for something that it isn't intended for (UI-ly speaking). I think that this is the main thing that leads to several smaller problems -- * the awkward use of ctl-? to switch, * the confusing interaction if you're not a mouse user, * the fact that the blurb line appears at the bottom (confusigly close to the ... of the other languages), * the weird interaction around the ... (I obviously tried to click it) * The fact that it's still steals a lot of screen space for something that most people shouldn't need (and DeinProgramm is making it take even more space?). But I think that the organization is a good direction for something that works nicely -- so how about this: * Revert all the way back to the plain hierarchical dialog that was used before the radio button thing (= go back to a simple UI) * Slap the current hierarchy on that, so that The Racket Language is first as it is now (and part of the hierarchy, top item), that preserves the current layout that encourages it. * To deal with the teaching languages, have them expanded only if the current language is the no-language thing (though I still think that that language is confusing more people than helping them). -- ((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] Revision to the Language Dialog
A few minutes ago, Robby Findler wrote: Well, I can't say that I'm excited about the prospect of going back to that dialog. My goal is to move towards no language dialog at all eventually and that change would not be a step in that direction. (Yes, I know that the goal is to get rid of it -- it's just that we now have this weird semi-hierarchy thing that is better expressed with just a plain hierlist...) -- ((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] Revision to the Language Dialog
On 2012-11-05 22:14:57 -0500, Matthias Felleisen wrote: -- I would use The Racket Language for the first line of the first item The latest dialog with this change looks really nice! FWIW, one thing that confused me was that the language selector in the bottom left still says Determine language from source when you click on The Racket Language in the dialog. I understand the connection here, but I imagine it'd be confusing for some people. Maybe just put Racket (#lang) or Racket (determine language from source) or something else instead? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
On Tue, Nov 6, 2012 at 10:48 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Okay, thanks for the feedback. I've pushed a change that mostly takes the suggestions, except no blue and instead of the parentheticals, I've linked to the docs. (I don't like how the links don't line up vertically so I'll fix that unless the whole thing is dumped, depending on what people say here.) I love it! Aside from the vertical alignment, I'd make the various #langs clickable, and have them change the #lang in the file (if it's unedited). -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
On 2012-11-06 14:27:42 -0500, Asumu Takikawa wrote: The latest dialog with this change looks really nice! FWIW, one thing that confused me was that the language selector in the bottom left still says Determine language from source when you click on The Racket Language in the dialog. Another thing: it was non-obvious to me that the indented options were clickable (and some aren't). Maybe an underline (like HTML links) would suffice? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. Robby On Tue, Nov 6, 2012 at 1:33 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2012-11-06 14:27:42 -0500, Asumu Takikawa wrote: The latest dialog with this change looks really nice! FWIW, one thing that confused me was that the language selector in the bottom left still says Determine language from source when you click on The Racket Language in the dialog. Another thing: it was non-obvious to me that the indented options were clickable (and some aren't). Maybe an underline (like HTML links) would suffice? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
+1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] My experience with Typed Racket
On Mon, Nov 5, 2012 at 5:46 PM, Dan Burton danburton.em...@gmail.com wrote: I've published a blog post about Typed Racket that I've been holding on to for a while. Mainly I intended it as feedback for Sam about what areas of TR I think can be improved, though it does provide a sort of tour through lots of Typed Racket features, so it should be readable by anyone with familiarity with Racket. http://unknownparallel.wordpress.com/2012/11/05/my-experience-with-typed-racket/ Thanks for the feedback. I think there are three main areas where you point to things that frustrated you about Typed Racket. 1. Some features of the structure system aren't supported across typed/untyped boundaries. This is certainly true, and we hope to address this in the future. Racket, and Racket's structure system, is big and complicated, and not all of it is easy to handle with Typed Racket. I will say that Typed Racket was never targeted at R5RS, and it's included struct support from the beginning. We called it Typed Scheme back then because the larger system was called PLT Scheme. 2. The grammar of types isn't user-extensible (and we need better syntax for optional arguments). This is a real limitation, and one that others (such as Neil and Eli) have complained about. We should just do both of these. However, it's wrong to say Typed Racket hijacks macros, and happens before them. What happens in your example is that types are not expressions, and thus the macro expander doesn't apply to them at all. This is just like how macro expansion doesn't happen in the parameter lists of functions. Typed Racket, in particular, happens roughly after macro expansion (for a full discussion of this, see our PLDI 2011 paper). Instead, we would add a new way to define type expanders, similar to `match` expanders or `provide` transformers. 3. Typed Racket often can't tell when a user-written function is a predicate for a type. You point to a number of places where this comes up (note that your `match` example has nothing to do with `match` -- writing the function out by hand doesn't affect the outcome). The main cause of this is that the problem is hard. Nothing short of sophisticated automatic theorem prover for a higher-order language (not something that currently exists) will allow the `valid-xexpr` function to be a predicate for a rich xexpr type. You also point out a genuine weakness in the reasoning system, that it doesn't recognize the special case when an expression has the *type* `False`, but doesn't come with a useful filter. I will look into addressing this. However, many of the cases where you're having trouble with this are places where you're probably trying to enforce things with the type system that TR isn't set up to do. Xexpressions are good example of this -- if you want a strongly-typed XML representation in TR, I'd do it the way you'd do it in haskell, with new structs. Otherwise, I'd just take a weak s-expression type, and impose dynamic checks, the way you'd do in untyped Racket. The same is true with character subsets -- you can stick with the `Char` type, or use a constructor to enforce a particular invariant. Thanks again for the feedback, and I hope you'll keep using Typed Racket. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] bug tracker won't let me query anymore
I logged into the bug tracker at bugs.racket-lang.org. What I see upon login now is the following: default User: dyoo Access: listdb *Racket Bugs*http://bugs.racket-lang.org/query/?database=default LoginYou do not have access to database: default. Please log in to another database I can't even log out anymore, so I don't know what do to do besides clear out my session cache or something. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Okay, I've push something to try to deal with this. Robby On Tue, Nov 6, 2012 at 3:35 PM, Robby Findler ro...@eecs.northwestern.edu wrote: OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Ouch. It satisfies the gui design laws so it passes this test. For an 'old timer' it doesn't truly work. Let's wait and see. -- Matthias On Nov 6, 2012, at 8:17 PM, Robby Findler wrote: Okay, I've push something to try to deal with this. Robby On Tue, Nov 6, 2012 at 3:35 PM, Robby Findler ro...@eecs.northwestern.edu wrote: OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Just to check: did you click on #lang racket when you had #lang racket in the buffer already? I need to improve that case a little bit. On Tue, Nov 6, 2012 at 7:40 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Ouch. It satisfies the gui design laws so it passes this test. For an 'old timer' it doesn't truly work. Let's wait and see. -- Matthias On Nov 6, 2012, at 8:17 PM, Robby Findler wrote: Okay, I've push something to try to deal with this. Robby On Tue, Nov 6, 2012 at 3:35 PM, Robby Findler ro...@eecs.northwestern.edu wrote: OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
No, I just played with the language dialog itself. On Nov 6, 2012, at 9:27 PM, Robby Findler wrote: Just to check: did you click on #lang racket when you had #lang racket in the buffer already? I need to improve that case a little bit. On Tue, Nov 6, 2012 at 7:40 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Ouch. It satisfies the gui design laws so it passes this test. For an 'old timer' it doesn't truly work. Let's wait and see. -- Matthias On Nov 6, 2012, at 8:17 PM, Robby Findler wrote: Okay, I've push something to try to deal with this. Robby On Tue, Nov 6, 2012 at 3:35 PM, Robby Findler ro...@eecs.northwestern.edu wrote: OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Ah, no I see what you mean. Let's keep this one for a while. On Nov 6, 2012, at 9:27 PM, Robby Findler wrote: Just to check: did you click on #lang racket when you had #lang racket in the buffer already? I need to improve that case a little bit. On Tue, Nov 6, 2012 at 7:40 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Ouch. It satisfies the gui design laws so it passes this test. For an 'old timer' it doesn't truly work. Let's wait and see. -- Matthias On Nov 6, 2012, at 8:17 PM, Robby Findler wrote: Okay, I've push something to try to deal with this. Robby On Tue, Nov 6, 2012 at 3:35 PM, Robby Findler ro...@eecs.northwestern.edu wrote: OH! I now get the confusion. Clicking on the teaching languages is the way one interacts with that part of the dialog but the #lang lines are just text and users of this thing will be completely confused by non-parallelism. Duh! Hm. Robby On Tue, Nov 6, 2012 at 2:24 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 Thank you for the experiment. I am coming to two conclusions: -- I think we're closer to getting it right -- I am beginning to think we dont' ever wish to abolish it. On Nov 6, 2012, at 3:09 PM, Asumu Takikawa wrote: On 2012-11-06 14:03:50 -0600, Robby Findler wrote: The docs links are meant to all be clickable (and I can certainly underline them). What were you expecting, exactly? I prefer not to make clicking on the #lang .. part edit the definitions window; I think copy and paste is probably clearer to the user. I didn't actually expect the '#lang ...' to change anything, but I could imagine thinking that it did and being confused. Similarly, it might not be obvious that the teaching languages are clickable without some visual distinction. Cheers, Asumu smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
I find confusing the caption at the bottom of the dialog that explains what the currently-selected language means. I think we could provide the same information more intuitively with mouseover tooltips, and lose the caption entirely. I'm not worried about showing a caption for the language the mouse is currently over, rather than the currently selected language, because people are accustomed to tooltips and expect them to come and go with where the mouse is. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Again with the language dialog
Clicking on #lang racket brings up a friendly dialog box saying you're really supposed to edit the buffer directly... That said, would you like me to add #lang racket to the definitions window? Sounds good so far... but if I say yes to accept this reasonable offer, it leaves me in an illegal state: in a student language with a #lang line. If we're going to add a #lang line, we should also switch to The Racket Language at the same time. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Again with the language dialog
I think you missed a revision to the dialog. The currently pushed version switches you to the The Racket Language when you click on one of the examples. Robby On Tue, Nov 6, 2012 at 9:59 PM, Stephen Bloch bl...@adelphi.edu wrote: Clicking on #lang racket brings up a friendly dialog box saying you're really supposed to edit the buffer directly... That said, would you like me to add #lang racket to the definitions window? Sounds good so far... but if I say yes to accept this reasonable offer, it leaves me in an illegal state: in a student language with a #lang line. If we're going to add a #lang line, we should also switch to The Racket Language at the same time. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Potential bug in path-url
I looked at your patch and it looks good overall. Could you add a test case or two to collects/tests/url.rkt (around line 184) and verify that the other test cases continue to pass? Jay On Tue, Nov 6, 2012 at 3:43 PM, Philippe Mechaï philippe.mec...@gmail.com wrote: Hi, I think there is a bug in the path-url function (from net/url). (url-string (path-url /tmp)) file:///tmp (url-string (path-url /tmp/)) file:///tmp As you can see the resulting URL is the same even if the path is a directory path. I believe that in the second case the URL should be file:///tmp/. This lead to an unexpected behaviour when using the result of path-url with combine-url/relative: (url-string (combine-url/relative (path-url /tmp/) foo.txt)) file:///foo.txt I've made a fix and created the pull request #166 on GitHub (https://github.com/plt/racket/pull/166) Could you please merge this change ? Also, it should be noted that the path-url and url-path are not symmetric as one could expect. Before my modification: (url-path (path-url /tmp/)) = #path:/tmp After: (url-path (path-url /tmp/)) = #path:/tmp/. I don't think it is a real problem but I thought it was worth mentioning. Regards, Philippe Mechaï _ Racket Developers list: http://lists.racket-lang.org/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 _ Racket Developers list: http://lists.racket-lang.org/dev
