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
