Hello,
stream-cons from racket's standard racket/stream.rkt is implemented as
a macro -stream-cons wrapped into a case-lambda.
This wrapping makes it strict in both arguments, contrary to the
traditional behaviour from SICP, srfi-40, srfi-41 etc.
For example:
> (define (foo) (display "called\n")
On Sat, Mar 5, 2011 at 5:11 PM, Matthias Felleisen wrote:
>
> Consider using Lazy Racket. -- Matthias
>
>
>
> On Mar 5, 2011, at 3:36 PM, Eugene Toder wrote:
>
>> Hello,
>>
>> stream-cons from racket's standard racket/stream.rkt is implemented as
&g
is really a separate topic.
So is the current behaviour of stream-cons in racket considered
correct? What's the recommended way of getting lazy behaviour in
(non-lazy) racket?
Eugene
On Sat, Mar 5, 2011 at 5:20 PM, Matthias Felleisen wrote:
>
> On Mar 5, 2011, at 5:18 PM, Eugene T
Mark,
I'm getting a similar impression. The only problem with this is that
racket/stream is available in racket by default and nothing in
documentation hints at experimental status. This confuses people who
use racket to learn scheme by working through SICP book.
Eugene
On Sat, Mar 5, 2011 at 7:
> So you shouldn't use it at all.
I wouldn't if I saw any hints :)
> The way the lazy language works, any function that is defined outside
> of the lazy world (and is not a struct constructor) is considered
> eager, so arguments that are sent to it are forced
Yes, that's pretty clear.
> (That's
> Either way, it clarifies how to deal with the state. (Which is why
> I'm surprised that the point didn't come up so far.)
Right, so we have stateless seqs that are only used to create
statefull producer of their values (iterators). For and any other
iteration construct ask for iterator and use
To clarify the last point. Say each seq has a method to create an
equivalent memoized seq, or return itself if memoization is not needed
(e.g. in-range). Memoized seq returns a memoizing iterator, that first
goes over previously calculated values, then starts storing newly
calculated values in seq
7 matches
Mail list logo
