Interesting, I see your point (not yet sure I adhere to it though). Anyway don't you think there is a readability problem with the mentioned code?
Laurent On Tue, Jun 11, 2013 at 7:15 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: > I don't like the idea of definitions inside and, at all. I'll elaborate > on why. > > Internal definitions and for-effect expressions make sense to me when > computing a single result value, where the last form in sequence is the > result and everything else is just context for that. > > They do not make sense to me in function arguments and other similar > contexts where, normally, each term's value contributes something to the > result. Every expression in a function application has a result that is > used. Every expression in an and form has a result that is used, if > evaluation doesn't stop earlier. > > If we started adding definitions to and, or, &c., then suddenly I have to > wonder which terms are used as definitions and which as arguments. Worse > yet, someone some day will want to put in an expression for effect in the > middle of an and, and then we'll have some real chaos. > > I'm all for definitions anywhere they can be clearly seen as not part of > the result form. Let's not put them in between arguments whose results > matter, please. > > Carl Eastlund > > > On Tue, Jun 11, 2013 at 12:49 PM, Laurent <laurent.ors...@gmail.com>wrote: > >> When I see what Robby is forced to write when following the Style: >> >> https://github.com/plt/racket/commit/09d636c54573522449a6591c805b38f72b6f7da8#L4R963 >> >> I cannot help but think that something is wrong somewhere (it may not be >> the Style, and in case it wasn't clear I'm certainly not criticizing >> Robby's code). >> Using `let' and `and' instead, although being a bit better since it >> avoids all the [else #f], is not that big an improvement: >> >> (define (get-x-spot char-width) >> (and >> char-width >> (let ([dc (get-dc)]) >> (and >> dc >> (let ([style (or (send (get-style-list) find-named-style "Standard") >> (send (get-style-list) find-named-style "Basic"))]) >> (and >> style >> (let*-values ([(fnt) (send style get-font)] >> [(xw _1 _2 _3) (send dc get-text-extent "x" fnt)]) >> (+ left-padding (* xw char-width))))))))) >> >> >> Actually I think here the right thing to do might be to allow for >> internal definitions inside `and': >> >> (define (get-x-spot char-width) >> (and char-width >> (define dc (get-dc)) >> dc >> (define style (or (send (get-style-list) find-named-style >> "Standard") >> (send (get-style-list) find-named-style >> "Basic"))) >> style >> (define fnt (send style get-font)) >> (define-values (xw _1 _2 _3) (send dc get-text-extent "x" fnt)) >> (+ left-padding (* xw char-width)))) >> >> >> Isn't it *much* more readable? (shorter, avoid rightward drift, less >> parens, vertical alignment) >> >> Since it's not the first time I find the need for such internal >> definitions in `and', maybe this is something to consider for future >> addition to Racket? Or have some people already identified some problems >> with this idea? >> >> I've played a bit with it if you want to try by your own: >> https://gist.github.com/Metaxal/5758394 >> >> (not sure I got it all good with syntax-parse though) >> >> Laurent >> >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
