I don't use continuations sufficiently to tell whether it would have been better or not. Anyway, I wasn't complaining at all about what you wrote or should have written -since in general I really only care about what I write myself- but about what I should have written if following the Style this way. The existence of `and-let*' shows there is another solution, so I'm happy with that.
Thank you all, Laurent On Tue, Jun 11, 2013 at 9:22 PM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > Maybe I should have used let/ec? Or a define-based variant of that? > > Robby > > > On Tuesday, June 11, 2013, Laurent wrote: > >> I'm also open to other solutions, but I find the (and (let (and (let (and >> ...))))) dance really inconvenient (verbose and not readable). >> >> So maybe it can be made cleaner, like not use `define' but `let' (as I >> actually did), and maybe use a keyword as Ian does, to show that it is not >> a normal expression, e.g.: >> (define (get-x-spot char-width) >> (and char-width >> #:let dc (get-dc) >> dc >> #:let style (or (send (get-style-list) find-named-style "Standard") >> (send (get-style-list) find-named-style "Basic")) >> style >> #:let fnt (send style get-font) >> #:let-values (xw _1 _2 _3) (send dc get-text-extent "x" fnt) >> (+ left-padding (* xw char-width)))) >> >> This way you would not need to care about the actual result of the >> `#:let's (and you could even add some `#:for-effect' actions if you like ;). >> >> Laurent >> >> On Tue, Jun 11, 2013 at 7:27 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: >> >> I don't have a big problem with the version that uses let. But my point >> isn't really about the code quality, it's about the can of worms being >> opened with the specific proposed solution. I'm open to other solutions. >> >> Also, re: definitions in and, bear in mind that definition macros do all >> kinds of crazy things. Some might expand into multiple forms, including >> for-effect expressions. That's another reason it's dangerous to put >> definitions into abnormal contexts that interpret them as anything other >> than a sequence of definitions and effects. You don't want spurious (void) >> or (values) or some such to spoil your conditional. >> >> Carl Eastlund >> >> On Tue, Jun 11, 2013 at 1:21 PM, Laurent <laurent.ors...@gmail.com>wrote: >> >> 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 >> sty >> >>
____________________ Racket Users list: http://lists.racket-lang.org/users
