<div dir="ltr">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:<div>
<br></div><div><div> (define/private (get-x-spot char-width)</div><div> (let/ec return</div><div> (unless char-width (return #f))</div><div> (define dc (get-dc))</div><div> (unless dc (return #f))</div>
<div> (define style (or (send (get-style-list) find-named-style "Standard")</div><div> (send (get-style-list) find-named-style "Basic")))</div><div> (unless style (return #f))</div>
<div> (define fnt (send style get-font))</div><div> (define-values (xw _1 _2 _3) (send dc get-text-extent "x" fnt))</div><div> (+ left-padding (* xw char-width))))</div></div><div><br></div><div style>
Robby</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 2:49 AM, Laurent <span dir="ltr"><<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I don't use continuations sufficiently to tell whether it would have been better or not.<br>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.<br>
<br></div>Thank you all,<br>Laurent<div><div class="h5"><br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 9:22 PM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe I should have used let/ec? Or a define-based variant of that?<span><font color="#888888"><div><br>
</div></font></span><div><span><font color="#888888">Robby</font></span><div><div><span></span><br><br>On Tuesday, June 11, 2013, Laurent wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>I'm also open to other solutions, but I find the (and (let (and (let (and ...))))) dance really inconvenient (verbose and not readable).<br><br>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.:<br>
<span style="font-family:courier new,monospace">(define (get-x-spot char-width)<br> (and char-width<br> #:let dc (get-dc)<br> dc<br> #:let style (or (send (get-style-list) find-named-style "Standard")<br>
(send (get-style-list) find-named-style "Basic"))<br> style<br> #:let fnt (send style get-font)<br> #:let-values (xw _1 _2 _3) (send dc get-text-extent "x" fnt)<br>
(+ left-padding (* xw char-width))))<br><br></span></div><div><span style="font-family:courier new,monospace"><span style="font-family:arial,helvetica,sans-serif">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 ;).</span><br>
</span></div><br><div><div><div class="gmail_extra">Laurent<br></div><div><br><div>On Tue, Jun 11, 2013 at 7:27 PM, Carl Eastlund <span dir="ltr"><<a>cce@ccs.neu.edu</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br>
<br></div>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.<span><font color="#888888"><br>
<br clear="all"><div>Carl Eastlund<br><br></div></font></span><div><div><div><div>On Tue, Jun 11, 2013 at 1:21 PM, Laurent <span dir="ltr"><<a>laurent.orseau@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Interesting, I see your point (not yet sure I adhere to it though).<br><br>
</div>Anyway don't you think there is a readability problem with the mentioned code?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">Laurent<br></font></span></div>
<div><div><div>
<br><br><div>On Tue, Jun 11, 2013 at 7:15 PM, Carl Eastlund <span dir="ltr"><<a>cce@ccs.neu.edu</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div>I don't like the idea of definitions inside and, at all. I'll elaborate on why.<br><br></div>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.<br>
<br></div>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.<br>
<br>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.<br>
<br></div>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.<span><font color="#888888"><br>
</font></span></div><div><span><font color="#888888"><br clear="all">
<div>Carl Eastlund</div>
<br><br></font></span><div><div>On Tue, Jun 11, 2013 at 12:49 PM, Laurent <span dir="ltr"><<a>laurent.orseau@gmail.com</a>></span> wrote:<br>
</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<div dir="ltr"><div><div><div><div><div><div><div>When I see what Robby is forced to write when following the Style:<br><a href="https://github.com/plt/racket/commit/09d636c54573522449a6591c805b38f72b6f7da8#L4R963" target="_blank">https://github.com/plt/racket/commit/09d636c54573522449a6591c805b38f72b6f7da8#L4R963</a><br>
</div><br>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).<br></div><div></div>Using `let' and `and' instead, although<span style="font-family:courier new,monospace"><span style="font-family:arial,helvetica,sans-serif"> being a bit better since it avoids all the [else #f], is not that big an improvement:</span><br>
<br>(define (get-x-spot char-width)<br> (and<br> char-width <br> (let ([dc (get-dc)])<br> (and<br> dc<br> (let ([style (or (send (get-style-list) find-named-style "Standard")<br> (send (get-style-list) find-named-style "Basic"))])<br>
(and<br> sty</span></div></div></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div>
</div>
</blockquote></div></div></div>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div></div>