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.ors...@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 <
> ro...@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 <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
