I would like the for/... comprehension macros to have #:while and #:until
clauses similar to the #:when and #:unless clauses. I often find I want to
short-circuit the sequence at some point, but there is no elegant way to do
it. I could probably write sequence-while and sequence-until, but I don'
I think this is a good idea. The technique to implement it is embedded
in `for/vector' (to handle a vector length), and I can generalize that
and move it into `for...'.
Also, I think the names `#:while' and `#:until' are too close to
`#:when' and `#:unless'. I suggest `#:break-when' and `#:break-u
I agree that #:while and #:until are easily confused with #:when and
#:unless. I slightly prefer #:stop- to #:break- as a prefix here, it seems
a more natural word. I like the idea of allowing these clauses at the end
of the body to give a notion of stopping after the current iteration. I
had be
+1
I've been using let/ec for this same functionality, and it's made me sad.
-Ian
- Original Message -
From: "Carl Eastlund"
To: "Matthew Flatt"
Cc: "PLT Developers"
Sent: Friday, September 14, 2012 11:49:20 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Short-circuiting compr
On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote:
> On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto wrote:
>> Compatibility with C code? Why not have the FFI convert them?
>>
>> Save space? I can see that. It won't help much if they're sent to math
>> library functions, though. Those will convert
As far as I can tell, if this pollutes TR programs in any interesting
way, then it would be a cause for concern.
Robby
On Fri, Sep 14, 2012 at 12:21 PM, John Clements
wrote:
>
> On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote:
>
>> On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto wrote:
>>> Compat
Two hours ago, John Clements wrote:
>
> I haven't followed the conversation closely enough to understand the
> ramifications of the proposed change, though; my guess is that the
> ffi can still address such arrays, it's just that computing with
> these values will require coercion. I could be okay
5 hours ago, Carl Eastlund wrote:
>
> Has this been brought up before? I can't recall. Does anyone else
> run into the same issue?
(I think that I brought this up when the comprehensions were first
discussed, pointing at the similar tool I have in Swindle which makes
implementing them very easy
My $0.02: I find #:while and #:when to be too close, and #:until and
#:unless even closer.
Robby
On Fri, Sep 14, 2012 at 2:30 PM, Eli Barzilay wrote:
> 5 hours ago, Carl Eastlund wrote:
>>
>> Has this been brought up before? I can't recall. Does anyone else
>> run into the same issue?
>
> (I t
I just tried to figure out what the second argument of dynamic-require does
when it's not a symbol, for the nth time. First of all, the current
interface -- 0, #false, and (void) as tokens for three rather arbitrary
modes of operation -- leaves much to be desired. These other modes should
probabl
At Fri, 14 Sep 2012 15:30:22 -0400, Eli Barzilay wrote:
> Four hours ago, Matthew Flatt wrote:
> >
> > Also, I think the names `#:while' and `#:until' are too close to
> > `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'.
> > Compare:
> >
> > > (for*/list ([j 2] [i 10] #:wh
On Sep 14, 2012, at 1:14 PM, Robby Findler wrote:
> My $0.02: I find #:while and #:when to be too close, and #:until and
> #:unless even closer.
More bike-shedding: I agree. In response to eli: I find the difficulty of
reading "break-when" to be an adequate cost to pay to highlight the differen
I like most of that and don't object to the rest, except for leaving out a
version of #:break-unless. Especially because "break" is already a
negative word. Just like #:unless (bad?) is more natural than #:when (not
(bad?)), #: (ok-to-continue?) is more natural than #:break (not
(ok-to-continue?)
TR doesn't support them anyways because there are only typed f64
vectors and not typed f32 vectors.
Jay
On Fri, Sep 14, 2012 at 11:28 AM, Robby Findler
wrote:
> As far as I can tell, if this pollutes TR programs in any interesting
> way, then it would be a cause for concern.
>
> Robby
>
> On Fri
I used the optimization coach for the first time today. First, a suggestion. I
wrestled with it for about five minutes before I realized that it applied only
to programs written in TR. An error message here would be *really* useful; I
kept mousing over and clicking and unclicking things to get t
At Fri, 14 Sep 2012 15:39:22 -0700,
John Clements wrote:
> I used the optimization coach for the first time today. First, a
> suggestion. I wrestled with it for about five minutes before I realized
> that it applied only to programs written in TR.
OC works on programs in any language, but in untyp
On Sep 14, 2012, at 4:50 PM, Vincent St-Amour wrote:
> At Fri, 14 Sep 2012 15:39:22 -0700,
> John Clements wrote:
>> I used the optimization coach for the first time today. First, a
>> suggestion. I wrestled with it for about five minutes before I realized
>> that it applied only to programs writ
The original message in this thread suggests that there is a type
Single-Flonum and that it is making Neil wrangle his code to be
careful about it.
Robby
On Fri, Sep 14, 2012 at 3:55 PM, Jay McCarthy wrote:
> TR doesn't support them anyways because there are only typed f64
> vectors and not type
18 matches
Mail list logo
