> There is a similar problem with for/product: . The initial 1 is that an
> integer, a real
> or a complex?
> (for/product: : Real ([i : Integer (in-range 0 5)]) (/ i))
Type Checker: Expected Integer, but got Exact-Rational in:
(for/product: : Real ((i : Integer (in-range 0 5))) (/ i))
It does
On 08/15/2012 08:05 AM, Sam Tobin-Hochstadt wrote:
On Wed, Aug 15, 2012 at 9:54 AM, Neil Toronto wrote:
BTW, what do you think of deprecating result annotations and using body
annotations instead?
I'm not sure yet.
This short exercise might convince you: implement `for/vector:' without
a b
I've attached my latest. It's possibly better.
On 08/15/2012 08:05 AM, Sam Tobin-Hochstadt wrote:
So then the first value computed is replicated everywhere? That seems
unappealing as well.
I've implemented #:fill in this one. If both #:length and #:fill are
given, the vector is created with
At Wed, 15 Aug 2012 17:38:18 +0200, Jens Axel Søgaard wrote:
> 2012/8/15 Neil Toronto :
>
> > Other options:
> >
> > 1. Raise an error when the vector isn't filled.
> > 2. Return a (Vectorof (U T #f)) (better than (Vectorof (U T 0))?).
> > 3. Always return a vector whose length is the number of
2012/8/15 Neil Toronto :
> Other options:
>
> 1. Raise an error when the vector isn't filled.
> 2. Return a (Vectorof (U T #f)) (better than (Vectorof (U T 0))?).
> 3. Always return a vector whose length is the number of iterations.
Or a variation of 2.:
4. Let the user supply the value to fi
On 08/15/2012 08:39 AM, J. Ian Johnson wrote:
- Original Message -
From: "Neil Toronto"
To: "Sam Tobin-Hochstadt"
So then the first value computed is replicated everywhere? That seems
unappealing as well.
It costs nothing, and if the #:length argument matches the number of
iterati
- Original Message -
From: "Neil Toronto"
To: "Sam Tobin-Hochstadt"
Cc: ""
Sent: Wednesday, August 15, 2012 10:36:36 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Wrapping loops for TR isn't working, and the type
annotations are for the
At Wed, 15 Aug 2012 07:54:16 -0600, Neil Toronto wrote:
> I wouldn't want to because `for/vector' is currently broken when
> #:length is given. (See PR 13029 and PR 13030.)
>
> I think the only way to fix it is to implement it like I did: expand to
> plain `for:' and mutate an external index.
I
On 08/15/2012 08:05 AM, Sam Tobin-Hochstadt wrote:
On Wed, Aug 15, 2012 at 9:54 AM, Neil Toronto wrote:
When #:length is given, it's similar in that it creates a vector outside the
loop and bangs values into it. But I have to start with (define vs (vector))
and then (set! vs (make-vector n v))
On Wed, Aug 15, 2012 at 9:54 AM, Neil Toronto wrote:
> On 08/15/2012 05:24 AM, Sam Tobin-Hochstadt wrote:
>>
>> On Tue, Aug 14, 2012 at 11:52 PM, Neil Toronto
>> wrote:
>>>
>>>
>>> Some typed "for" loops would have to be reimplemented, unless inference
>>> improves a lot. To make this easier, I'v
On 08/15/2012 05:24 AM, Sam Tobin-Hochstadt wrote:
On Tue, Aug 14, 2012 at 11:52 PM, Neil Toronto wrote:
Some typed "for" loops would have to be reimplemented, unless inference
improves a lot. To make this easier, I've attached an example implementation
of `for/vector:' and `for*/vector:'. It
On Tue, Aug 14, 2012 at 11:52 PM, Neil Toronto wrote:
>
> Some typed "for" loops would have to be reimplemented, unless inference
> improves a lot. To make this easier, I've attached an example implementation
> of `for/vector:' and `for*/vector:'. It allows both body and result
> annotations, hand
I like the idea of wrapping Racket's standard "for" loops with a few
annotations and letting inference figure out the rest of the types.
The problem is, it doesn't work very well.
1. Even though the loop's type is technically optional, it seems to
always be required.
2. Many simple loops d
13 matches
Mail list logo
