[racket] Style or and/define

From: Laurent (laurent.orseau at gmail.com)
Date: Wed Jun 12 06:32:05 EDT 2013

Thanks for the explanation Robby. It's actually not bad, just a bit more
verbose, but it can then be tailored easily:

(define-syntax-rule (let/ec/check check body ...)
  (let/ec return
    (define (check v)
      (unless v (return #f)))
    body ...

(define/private (get-x-spot char-width)
  (let/ec/check check
    (check char-width)
    (define dc (get-dc))
    (check dc)
    (define style (or (send (get-style-list) find-named-style "Standard")
                      (send (get-style-list) find-named-style "Basic")))
    (check 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))))

I think it's quite ok then. Good idea.


On Wed, Jun 12, 2013 at 12:15 PM, Robby Findler <robby at eecs.northwestern.edu
> wrote:

> It would have looked like this. "ec" means escaping continuation: it is
> much weaker than a real continuation, something very much like 'return' or
> 'break' in other languages. Except that in Racket you have a little bit
> more fine-grained control over where you end up escaping out of (it isn't
> tied to a function or a loop). In this case, tho, you'd want something that
> returns from the function. The code would look like this:
>   (define/private (get-x-spot char-width)
>     (let/ec return
>       (unless char-width (return #f))
>       (define dc (get-dc))
>       (unless dc (return #f))
>       (define style (or (send (get-style-list) find-named-style "Standard")
>                         (send (get-style-list) find-named-style "Basic")))
>       (unless style (return #f))
>        (define fnt (send style get-font))
>       (define-values (xw _1 _2 _3) (send dc get-text-extent "x" fnt))
>       (+ left-padding (* xw char-width))))
> Robby
> On Wed, Jun 12, 2013 at 2:49 AM, Laurent <laurent.orseau at gmail.com> wrote:
>> 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/a4e85d69/attachment.html>

Posted on the users mailing list.