Re: [racket-dev] Racket docs and data-driven design
On Sep 16, 2011, at 11:52 AM, Shriram Krishnamurthi wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) Interesting. I'm with you: I tell my students to use else to capture true none of the above cases that can't easily be described directly, e.g. (define (size thing) (cond [(string? thing) (string-length thing)] [(real? thing) (abs thing)] [(image? thing) (* (image-width thing) (image-height thing))] [else (error 'size I don't know how to handle that type.)])) Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Racket docs and data-driven design
I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
The same is true of HtDP: http://htdp.org/2003-09-26/Book/curriculum-Z-H-13.html#node_chap_9 and HtDP 2e: http://www.ccs.neu.edu/home/matthias/HtDP2e/htdp2e-part2.html . (search for [else in a similar way). On Fri, Sep 16, 2011 at 11:52 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) Shriram _ 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 docs and data-driven design
Why is else evil? I can see how it might be pragmatic to avoid it in a language without contracts, but I'm having trouble seeing evil. Robby On Fri, Sep 16, 2011 at 10:52 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) 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] Racket docs and data-driven design
I don't like it either because it makes the function a contract violator: (define (listy l) (cond [(empty? l) ...] [else ... (first l) ...])) (define (f x) ... (listy 5) ...) f breaks listy's contract, but it goes undetected in most of Racket and all of HtDP and listy gets blamed for breaking first's contract. A student sees an error message about first, not listy. If you had [(cons? ...) ...], then you'd get all questions were false inside listy, which is nicer. I understand that signatures are meant to solve this, but they aren't part of HtDP yet. On the other hand, if the contracts are there, I like else because each cond eliminates one variant and there is finally just one variant left. (Note: I only like this if it is unlikely I will add more variants. I dislike that type-case from PLAI has else, for example.) Jay On Fri, Sep 16, 2011 at 10:13 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Why is else evil? I can see how it might be pragmatic to avoid it in a language without contracts, but I'm having trouble seeing evil. Robby On Fri, Sep 16, 2011 at 10:52 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) 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 -- 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 docs and data-driven design
In addition to what Jay said, when the datatype evolves, it's harder for someone reading the code to tell whether the else was meant to cover only one other case (and now there's two, and someone forgot to update the function) or truly all the other cases. When you have crisp predicates, I see no excuse for using else -- it's intellectually sloppy and causes both missed early-errors (as Jay shows) and later pain. For really complex predicates, it makes sense: (cond [(prime (foo (bar x))) ...] [else ...]) offers many advantages over (cond [(prime (foo (bar x))) ...] [(not (prime (foo (bar x ...]) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
I admit sloppiness. On Sep 16, 2011, at 12:49 PM, Shriram Krishnamurthi wrote: In addition to what Jay said, when the datatype evolves, it's harder for someone reading the code to tell whether the else was meant to cover only one other case (and now there's two, and someone forgot to update the function) or truly all the other cases. When you have crisp predicates, I see no excuse for using else -- it's intellectually sloppy and causes both missed early-errors (as Jay shows) and later pain. For really complex predicates, it makes sense: (cond [(prime (foo (bar x))) ...] [else ...]) offers many advantages over (cond [(prime (foo (bar x))) ...] [(not (prime (foo (bar x ...]) 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
