[racket] Style or and/define

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