[racket] Style or and/define

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
<robby at 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 <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
>>          sty
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130612/0c7ddb38/attachment.html>