I wrote a macro once to `flatten' this kind of idiom, because I was
writing code where I was doing a *lot* of this. It lets you mix
let-style bindings with tests that throw an error if they fail.
Warning: there is almost certainly a better way to write it (it is among
the first `real' macros I wr
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)
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 t
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 w
Ah, very good, that's much better. Mystery solved.
(though I do kind of like the `and-let' with `#:let' keywords, since it
avoids the paren-verbosity of `let'.)
Thanks Клочков and Matthias,
Laurent
On Tue, Jun 11, 2013 at 8:44 PM, Matthias Felleisen wrote:
>
> Nice, I wish Oleg had also defined
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, li
On Tue, Jun 11, 2013 at 10:39 AM, Клочков Роман wrote:
> You may use srfi/2 http://docs.racket-lang.org/srfi-std/srfi-2.html
>
> (require srfi/2)
> (define (get-x-spot char-width)
> (and-let*
>([char-width]
> [dc (get-dc)]
>
> [style (or (send (get-style-list) find-named-style "Stand
Nice, I wish Oleg had also defined let*-and, which is what I think you really
want here:
(define-syntax let*-and
(syntax-rules ()
[(_ ((x:id e:expr) (y:id f:expr) ...) body0:def-or-expr body1 ...)
(let ((x:id e:expr))
(and x:id (let*-and ((y:id f:expr) ...) body0:def-or-expr b
You may use srfi/2 http://docs.racket-lang.org/srfi-std/srfi-2.html
(require srfi/2)
(define (get-x-spot char-width)
(and-let*
([char-width]
[dc (get-dc)]
[style (or (send (get-style-list) find-named-style "Standard")
(send (get-style-list) find-named-style "B
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 expres
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 o
This code appears to be equivalent to using Maybe in Haskell, with the
same kind of indentation issues:
case char-width of
Nothing -> Nothing
Just n -> do stuff, get new Maybe, case new-maybe of
Nothing -> Nothing
Just x -> do stuff ... etc...
In Haskell, one composes these with b
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 wrote:
> I don't like the idea of definitions inside and, at all. I'll elaborate
> on why.
defines to this extended and,
but that requires a local-expand. Not sure if I want to do that.
-Ian
- Original Message -
From: "Sean McBeth"
To: "Laurent"
Cc: "Racket Mailing List"
Sent: Tuesday, June 11, 2013 1:11:26 PM GMT -05:00 US/Canada Eastern
S
On Tue, Jun 11, 2013 at 7:11 PM, Sean McBeth wrote:
> Okay, there is one difference between our examples, in that yours will
> short-circuit and mine won't. However, if that is not a concern and you're
> looking more for readability, you could even use local define
>
> (define (get-x-spot char-wi
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 sens
Okay, there is one difference between our examples, in that yours will
short-circuit and mine won't. However, if that is not a concern and you're
looking more for readability, you could even use local define
(define (get-x-spot char-width)
(define dc (and char-width (get-dc)))
(define style (a
Would let* mostly achieve this?
(define (get-x-spot char-width)
(let* ([dc (and char-width (get-dc))]
[style (and dc (or (send (get-style-list) find-named-style
"Standard")
(send (get-style-list) find-named-style
"Basic")))]
[fnt (and style (send sty
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
Robb
19 matches
Mail list logo
