[racket] Style or and/define

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130611/2a861cdc/attachment.html>