I've been converting a bunch of Python to Racket lately, and I have a
lot of loops that use break and continue. I end up turning them into:
(let/ec break
(for (...)
(let/ec continue
; do some work
(when this-iteration-isn't-what-i-want
(continue))
; do more expensiv
ros are so much more
than Python's for - they can produce values. Don't throw everything into the
void :)
-Ian
Original Message -
From: Jay Kominek
To: dev
Sent: Fri, 27 Jun 2014 17:15:45 -0400 (EDT)
Subject: [racket-dev] for loops with interleaved escape continuations
I'
On Fri, Jun 27, 2014 at 8:40 PM, J. Ian Johnson wrote:
> One is that #:when in for-clauses allows you to skip iterations, but you want
> it in the body. This is a cosmetic difference that you can get around by
> doing #:when (begin imperative-stuff-before-guard guard). If you want ecs to
> esca
Hi Jay,
Have not been following Racket development too closely lately, but
perhaps you might find this helpful?
http://planet.racket-lang.org/display.ss?package=while-loop.plt&owner=dyoo
_
Racket Developers list:
http://lists.racket-lang.org/dev
In principle I like this #:ec idea, but I would feel more comfortable if you
explored the whole range of for loops and their interactions with this new
feature. -- Matthias
On Jun 28, 2014, at 6:54 AM, Jay Kominek wrote:
> On Fri, Jun 27, 2014 at 8:40 PM, J. Ian Johnson wrote:
>> One is
I think this is a good idea, and something that I've wanted for a long
time. But there are ways to make it much better, and generalize to all
loops.
First, recognize that a `for/...` loop is really a recursive function,
which is passing along a bunch of arguments. In this setting,
`continue` means
If adding break&continue features to your fancy iteration syntax, I
propose that any uses of these features in source code be somehow very
prominent.
For example, perhaps there is a keyword that must be at the top of the
fancy iteration form, something like
"#:enable-continue-here-because-pro
I disagree strongly that this is un-rackety. Consider the following loop:
(define v )
(let loop ([i 100])
(define e (vector-ref v i))
(cond [(zero? i) null]
[(= 999 e) null]
[(even? e) (loop (add1 i))]
[else (cons e (loop add1 i))]))
I don't think that's un-
On Jul 1, 2014, at 3:46 PM, Sam Tobin-Hochstadt wrote:
> I disagree strongly that this is un-rackety. Consider the following loop:
>
> (define v )
> (let loop ([i 100])
> (define e (vector-ref v i))
> (cond [(zero? i) null]
> [(= 999 e) null]
> [(even? e) (loop (add1 i))
On Wed, Jul 2, 2014 at 12:52 AM, John Clements
wrote:
>
> On Jul 1, 2014, at 3:46 PM, Sam Tobin-Hochstadt wrote:
>
>> I disagree strongly that this is un-rackety. Consider the following loop:
>>
>> (define v )
>> (let loop ([i 100])
>> (define e (vector-ref v i))
>> (cond [(zero? i) null]
>>
Interestingly enough, I tried to explain this idea to the Imperative Advanced
Placement crowd in the 1990s. With functional programming -- control from
tail-recursive functions -- is more expressive than programming with limited
loops because you can (1) break/resume/continue/foobar your 'loops
Loop syntax and sugar is fine. And having "#:continue" and "#:break"
keywords at the top of the form is sufficient warning of surprises
ahead, IMHO.
I do have a minor ongoing concern that people coming from other
languages lately latch onto the "for" family of forms from the start,
don't get
On Jul 2, 2014, at 2:26 PM, Neil Van Dyke wrote:
> Loop syntax and sugar is fine. And having "#:continue" and "#:break"
> keywords at the top of the form is sufficient warning of surprises ahead,
> IMHO.
>
> I do have a minor ongoing concern that people coming from other languages
> lately l
13 matches
Mail list logo
