Re: [racket-dev] plea for short planet syntax in student languages?
We have had students that write (require racket) and happily program away -- actually are very unhappy due to bugs. How about this experiment: everyone teach in plain Racket for a while and see whether teaching language restrictions are really needed. On Oct 5, 2011, at 2:37 PM, Shriram Krishnamurthi wrote: In the language I use in my class, I offer require: only-in except-in prefix-in rename-in combine-in planet provide: all-defined-out all-from-out rename-out except-out prefix-out struct-out combine-out protect-out and my students use most of these. I am not aware of a student ever getting into real trouble because of this. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] plea for short planet syntax in student languages?
What they import is orthogonal to the syntax for importing. How about this experiment: everyone teach in plain Racket for a while and see whether teaching language restrictions are really needed. That would be a good experiment. My own suspicion is that getting rid of implicit begin will prove to be absolutely vital, and will cover about 75% of all the problems. There may be one or two more important cases, followed by a very long tail. But if we only think in terms of language restrictions, I don't think we'll make much progress -- unless we're willing to also consider (small) language changes (eg, replacing define with defvar and deffun so we can better distinguish intent and thereby provide better errors). Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
Sam wrote: Unlike, say, `syntax-parse', `match' isn't designed for the use-case of building ASTs while matching. Wait, what? That's exactly what I want to use it for when writing toy interpreters for pedagogical purposes. Or am I misunderstanding what you're saying here? I want to do PLAI-style things, but with `match' instead of `type-case'. --PR _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] open untagged files in blank language level?
+1, but for different reasons than editing html files... I'd like to see the use the language defined in the source become the default for all purposes -- so at least when you open a file that does have a `#lang' line, or when you type it in, the non-use the language defined in the source languages should make it ask you if you want to switch to it (to the use the language defined in the source language). If anything, just the name of the use the language defined in the source language is a very long one, which is unfortunate since it's often the one that gets recommended often. Two hours ago, John Clements wrote: Currently, opening a file that doesn't begin with a #lang line results in a window whose language level is inherited from the buffer that was foremost when the open-file was issued (IIUC). I think this is a mistake. I think that instead, the language level should revert to Use the language defined in the source. My first argument for this is a bit silly and technical; this behavior is inconsistent with the other behavior of the save toolbar button show/hide, which appears to be that the button is shown when the text that DrR would save is different from the last-saved version. This means that changing language levels shows the save button, and therefore (I claim) so should opening a file without #lang info in a non-use-defined-in-source language level. However, I think an even better fix is just to open such files in the use-lang-defined-in-source language level. Upside of this change: people who edit, say, .html or .txt files in DrRacket won't get an ugly surprise when they save them. This is more insidious in the case of files such as .html which are intended to be interpreted by a different tool (in this case a web browser), which will barf on the inserted #lang line. Downside of this change: people who *create student-language files outside of DrR* will then have to set the language level when opening those files. This seems uncommon to me. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 1:12 PM, Eli Barzilay e...@barzilay.org wrote: A few minutes ago, Prabhakar Ragde wrote: Sam wrote: Unlike, say, `syntax-parse', `match' isn't designed for the use-case of building ASTs while matching. Wait, what? That's exactly what I want to use it for when writing toy interpreters for pedagogical purposes. Or am I misunderstanding what you're saying here? I want to do PLAI-style things, but with `match' instead of `type-case'. --PR Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. It seems difficult to argue that this: (struct plus (left right)) (define (parse sexp) (match sexp [`(+ ,lhs ,rhs) (plus (parse lhs) (parse rhs))] [(? number?) sexp])) is not build ing the ast while matching. Nevertheless, this is not what Sam was talking about. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
Just now, Robby Findler wrote: On Thu, Oct 6, 2011 at 1:12 PM, Eli Barzilay e...@barzilay.org wrote: A few minutes ago, Prabhakar Ragde wrote: Sam wrote: Unlike, say, `syntax-parse', `match' isn't designed for the use-case of building ASTs while matching. Wait, what? That's exactly what I want to use it for when writing toy interpreters for pedagogical purposes. Or am I misunderstanding what you're saying here? I want to do PLAI-style things, but with `match' instead of `type-case'. --PR Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. It seems difficult to argue that this: (struct plus (left right)) (define (parse sexp) (match sexp [`(+ ,lhs ,rhs) (plus (parse lhs) (parse rhs))] [(? number?) sexp])) is not build ing the ast while matching. Nevertheless, this is not what Sam was talking about. OK, ... while matching a particular pattern. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] open untagged files in blank language level?
Two hours ago, John Clements wrote: Currently, opening a file that doesn't begin with a #lang line results in a window whose language level is inherited from the buffer that was foremost when the open-file was issued (IIUC). No, it defaults to whatever language you last chose in the language level (or in the popup at the bottom of the drracket window), unless it sees a #lang line at the beginning, in which case it uses the 'use the language declared in the source' language (but that does not count as changing that last choice). I think this is a mistake. I think that instead, the language level should revert to Use the language defined in the source. I don't want to default to 'use language in source' because of students that have chose one of the teaching languages. They should keep getting that student language over and over and not having to explicitly keep re-choosing it. Unless I misunderstand the proposal somehow? On Thu, Oct 6, 2011 at 1:20 PM, Eli Barzilay e...@barzilay.org wrote: I'd like to see the use the language defined in the source become the default for all purposes Until the teaching languages work well in this mode, I oppose this change. Once they do, I'm all for it. -- so at least when you open a file that does have a `#lang' line, or when you type it in, the non-use the language defined in the source languages should make it ask you if you want to switch to it (to the use the language defined in the source language). When you open a file that begins with #lang DrRacket already just changes the language level (but nothing detects when you type it). If anything, just the name of the use the language defined in the source language is a very long one, which is unfortunate since it's often the one that gets recommended often. Easy to agree here. :) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On 10/06/2011 01:20 PM, Eli Barzilay wrote: Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. Well I'll be darned. I suppose this shows just how deeply I hold assumptions about order and shortcutting. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] open untagged files in blank language level?
On Oct 6, 2011, at 11:30 AM, Robby Findler wrote: Two hours ago, John Clements wrote: Currently, opening a file that doesn't begin with a #lang line results in a window whose language level is inherited from the buffer that was foremost when the open-file was issued (IIUC). No, it defaults to whatever language you last chose in the language level (or in the popup at the bottom of the drracket window), unless it sees a #lang line at the beginning, in which case it uses the 'use the language declared in the source' language (but that does not count as changing that last choice). I think this is a mistake. I think that instead, the language level should revert to Use the language defined in the source. I don't want to default to 'use language in source' because of students that have chose one of the teaching languages. They should keep getting that student language over and over and not having to explicitly keep re-choosing it. Unless I misunderstand the proposal somehow? Yes, I believe you misunderstand my proposal. In particular, I believe we agree that opening a new file or tab should create a file that's in the current language level. If there's any disagreement, it's about what should happen when an existing file--specifically, one that doesn't begin with #lang--is opened. Unless I'm missing something, this means that the only time students will have to re-select the language level is when they download a file that's intended to be evaluated in a student language, but that doesn't have a #lang line in it. Right? In my particular case, I had a program for students that reads in a rhythm from a text file. The problem was that when students opened this text file in a drracket editor and changed it a bit and saved it, all of a sudden their rhythms came out as incredibly bizarre, because of the hidden first lines of the text file. If anything, just the name of the use the language defined in the source language is a very long one, which is unfortunate since it's often the one that gets recommended often. Easy to agree here. :) Yes, I totally agree with this. This name will disappear when language levels disappear, right? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] open untagged files in blank language level?
10 minutes ago, John Clements wrote: If anything, just the name of the use the language defined in the source language is a very long one, which is unfortunate since it's often the one that gets recommended often. Easy to agree here. :) Yes, I totally agree with this. This name will disappear when language levels disappear, right? Since it still going to be around for a while, how about changing: Use the language declared in source (ctl-U) to #lang: Use the language in source (ctl-U) ? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
Do we have performance measurements that show the importance of such reorderings? Robby On Thursday, October 6, 2011, Neil Toronto neil.toro...@gmail.com wrote: On 10/06/2011 01:20 PM, Eli Barzilay wrote: Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. Well I'll be darned. I suppose this shows just how deeply I hold assumptions about order and shortcutting. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
In Le Fessant and Maranget, ICFP 2001, they have measurements that show a 30% speedup of whole (toy) programs, with a similar but smaller suite of optimizations. Given the extensibility of `match', the performance difference can be made arbitrarily large. For example, Eli's example doesn't call the `one??' function, which could take arbitrarily long (imagine a database query). On Thu, Oct 6, 2011 at 5:56 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Do we have performance measurements that show the importance of such reorderings? Robby On Thursday, October 6, 2011, Neil Toronto neil.toro...@gmail.com wrote: On 10/06/2011 01:20 PM, Eli Barzilay wrote: Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. Well I'll be darned. I suppose this shows just how deeply I hold assumptions about order and shortcutting. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? Jay On Thu, Oct 6, 2011 at 4:03 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: In Le Fessant and Maranget, ICFP 2001, they have measurements that show a 30% speedup of whole (toy) programs, with a similar but smaller suite of optimizations. Given the extensibility of `match', the performance difference can be made arbitrarily large. For example, Eli's example doesn't call the `one??' function, which could take arbitrarily long (imagine a database query). On Thu, Oct 6, 2011 at 5:56 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Do we have performance measurements that show the importance of such reorderings? Robby On Thursday, October 6, 2011, Neil Toronto neil.toro...@gmail.com wrote: On 10/06/2011 01:20 PM, Eli Barzilay wrote: Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. Well I'll be darned. I suppose this shows just how deeply I hold assumptions about order and shortcutting. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 6:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote: In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? No, definitely not! `match' might test components in whatever order it wants, but the semantics of when a match is found is just top-to-bottom, and `match' always takes the first successful match. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Oct 6, 2011 at 6:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote: In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? No, definitely not! `match' might test components in whatever order it wants, but the semantics of when a match is found is just top-to-bottom, and `match' always takes the first successful match. So in this case, match has to call one?? because all the other components match on the first case? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 6:23 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Oct 6, 2011 at 6:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote: In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? No, definitely not! `match' might test components in whatever order it wants, but the semantics of when a match is found is just top-to-bottom, and `match' always takes the first successful match. So in this case, match has to call one?? because all the other components match on the first case? Exactly. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
Given all this talk of optimization, I'm still amazed that my original example failed. Basically, the ordering optimization decided that (and (pair? (cdr e)) (parse (car (cdr e is cheaper than (equal? '+ (car e)) Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
(And I feel obliged here to suggest that there should be some way to write test cases for this kind of thing -- ones that are not based on timing things but ones that are based on feeding some expressions into a compiler and making sure they get re-ordered in an expected way.) Robby On Thu, Oct 6, 2011 at 6:22 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: That certainly doesn't seem right. It should prefer the pair check, but it's supposed to treat calling embedded expressions as slow. I'll take a look at that. On Oct 6, 2011 7:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Given all this talk of optimization, I'm still amazed that my original example failed. Basically, the ordering optimization decided that (and (pair? (cdr e)) (parse (car (cdr e is cheaper than (equal? '+ (car e)) Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] open untagged files in blank language level?
On Oct 6, 2011, at 4:35 PM, John Clements cleme...@brinckerhoff.org wrote: If there's any disagreement, it's about what should happen when an existing file--specifically, one that doesn't begin with #lang--is opened. Unless I'm missing something, this means that the only time students will have to re-select the language level is when they download a file that's intended to be evaluated in a student language, but that doesn't have a #lang line in it. Right? In my particular case, I had a program for students that reads in a rhythm from a text file. The problem was that when students opened this text file in a drracket editor and changed it a bit and saved it, all of a sudden their rhythms came out as incredibly bizarre, because of the hidden first lines of the text file. How about this: when you open an existing file that has no prologue or #lang, it opens in text mode: the Check Syntax and Run buttons are both disabled. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
