At Sun, 27 Mar 2011 12:36:21 -0400, Eli Barzilay wrote:
`sequence-filter', and `sequence-add-between'. The repair involved
adding `sequence-generate*', which starts a sequence in a way that
is consistent with using state but doesn't use state if the sequence
itself isn't stateful.
*
5 minutes ago, Matthew Flatt wrote:
There's a naming-convention clash between
* `in-...' for sequences (sometimes streams) especially intended
for direct use in `for' forms, and
* operations on streams and sequences, which would normally start
`stream-' or `sequence-'.
I see
On Mar 17, 2011, at 15:34 , Matthias Felleisen wrote:
I think we should stay away from 'stream' here.
If Racket had grown out of the Unix tradition, I'd
be fine with it. But we partially grew out the
functional community, and they use 'stream' for
a narrower concept.
Maybe a silly
A week ago, Matthew Flatt wrote:
At Thu, 17 Mar 2011 16:13:26 -0400, Eli Barzilay wrote:
Yesterday, Matthew Flatt wrote:
I see your point about generator, and so I agree that we
should use a different term. I'm not too happy with the term
producer, but I don't yet have a better
Two reactions:
1. I think we should stay away from 'stream' here.
If Racket had grown out of the Unix tradition, I'd
be fine with it. But we partially grew out the
functional community, and they use 'stream' for
a narrower concept.
2. My hunch is that immutable 'things' are what we
want.
At Thu, 17 Mar 2011 15:34:17 -0400, Matthias Felleisen wrote:
1. I think we should stay away from 'stream' here.
If Racket had grown out of the Unix tradition, I'd
be fine with it. But we partially grew out the
functional community, and they use 'stream' for
a narrower concept.
Unless
On Thu, Mar 17, 2011 at 3:34 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
1. I think we should stay away from 'stream' here.
If Racket had grown out of the Unix tradition, I'd
be fine with it. But we partially grew out the
functional community, and they use 'stream' for
a narrower
On Mar 17, 2011, at 3:38 PM, Matthew Flatt wrote:
At Thu, 17 Mar 2011 15:34:17 -0400, Matthias Felleisen wrote:
1. I think we should stay away from 'stream' here.
If Racket had grown out of the Unix tradition, I'd
be fine with it. But we partially grew out the
functional community, and
Matthew wrote Streams include lists and lazy lists as produced by `stream-cons'
(i.e., the usual one instead of the one currently exported by
`racket/stream').
so I think the answer is 1.
Robby
On Thu, Mar 17, 2011 at 2:42 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Mar 17,
Is the question: is stream-cons a macro or a function? If it is a
function, the answer has to be diverge. I think it being a macro is a
little weird, but it being a function and the answer not being 1 is
non-streamy.
Jay
2011/3/17 Robby Findler ro...@eecs.northwestern.edu:
Matthew wrote Streams
I don't see how you go from this sentence to your conclusion,
so I will wait for Matthew's response. -- Matthias
On Mar 17, 2011, at 3:49 PM, Robby Findler wrote:
Matthew wrote Streams include lists and lazy lists as produced by
`stream-cons'
(i.e., the usual one instead of the one
That's the heart of the question, its distillation to a one-liner.
The real question how a list can __be__ a stream and how a LR stream can __be__
a stream. At a minimum, I would have expected a list can be converted into a
stream and a lazy stream can be converted into a stream. (And the
At Thu, 17 Mar 2011 15:42:40 -0400, Matthias Felleisen wrote:
What does
(stream-first (stream-cons 1 (infinite-loop)))
produce?
1
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
I believe the intention is you get somethig like this
(stream-cons e1 e2)
=
(make-stream-cons (delay e1) (delay e2))
and stream-car and stream-cdr are selectors for the stream-cons struct
that also force the promises.
Robby
On Thu, Mar 17, 2011 at 2:51 PM, Jay McCarthy
On Thu, Mar 17, 2011 at 2:53 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
That's the heart of the question, its distillation to a one-liner.
The real question how a list can __be__ a stream and how a LR stream can
__be__ a stream. At a minimum, I would have expected a list can be
On Mar 17, 2011, at 3:54 PM, Matthew Flatt wrote:
At Thu, 17 Mar 2011 15:42:40 -0400, Matthias Felleisen wrote:
What does
(stream-first (stream-cons 1 (infinite-loop)))
produce?
1
Then I definitely recommend picking a different word for this library:
flow
series
river
At Thu, 17 Mar 2011 15:53:51 -0400, Matthias Felleisen wrote:
That's the heart of the question, its distillation to a one-liner.
The real question how a list can __be__ a stream and how a LR stream can
__be__ a stream.
It's in the same way that a list can be a sequence and a vector can be
On Mar 17, 2011, at 4:10 PM, Matthew Flatt wrote:
At Thu, 17 Mar 2011 15:53:51 -0400, Matthias Felleisen wrote:
That's the heart of the question, its distillation to a one-liner.
The real question how a list can __be__ a stream and how a LR stream can
__be__ a stream.
It's in the
Yesterday, Matthew Flatt wrote:
At Wed, 16 Mar 2011 13:21:28 -0400, Eli Barzilay wrote:
Generators include the result of `generator' and input
ports. (The `generator?' predicate currently returns false
for input ports, but that could change.)
I'd rather see these generators
On Mar 17, 2011, at 4:46 PM, Matthew Flatt wrote:
I disagree only because of the lazy nature of stream __construction__,
the potential confusion for first-timers, and the potential confusion with
some srfi or other.
Can you provide an example that would create confusion?
See recent
At Thu, 17 Mar 2011 16:12:22 -0400, Matthias Felleisen wrote:
On Mar 17, 2011, at 4:10 PM, Matthew Flatt wrote:
At Thu, 17 Mar 2011 15:53:51 -0400, Matthias Felleisen wrote:
That's the heart of the question, its distillation to a one-liner.
The real question how a list can __be__ a
At Thu, 17 Mar 2011 16:48:45 -0400, Matthias Felleisen wrote:
On Mar 17, 2011, at 4:46 PM, Matthew Flatt wrote:
I disagree only because of the lazy nature of stream __construction__,
the potential confusion for first-timers, and the potential confusion with
some srfi or other.
Here's a proposal for cleaning up `racket/stream'.
The first part of the proposal is terminology:
* A _sequence_ is any kind of input to `for'. That is, it's a generic
ordered collection of elements that supports iteration through the
elements.
Sequences include lists, vectors, and
Three hours ago, Matthew Flatt wrote:
Here's a proposal for cleaning up `racket/stream'.
The first part of the proposal is terminology:
[...]
That's close to what we talked about, with the addition of generators.
Generators include the result of `generator' and input
ports. (The
+1
2011/3/16 Matthew Flatt mfl...@cs.utah.edu:
Here's a proposal for cleaning up `racket/stream'.
The first part of the proposal is terminology:
* A _sequence_ is any kind of input to `for'. That is, it's a generic
ordered collection of elements that supports iteration through the
At Wed, 16 Mar 2011 13:21:28 -0400, Eli Barzilay wrote:
Generators include the result of `generator' and input
ports. (The `generator?' predicate currently returns false for
input ports, but that could change.)
I'd rather see these generators be only thunks (explained below) --
On Mar 5, 2011, at 10:32 PM, Eli Barzilay wrote:
So you shouldn't use it at all.
Eli, this remark suggests that 'stream' is mis-documented and that it should be
moved somewhere else for the next release, before it does more harm (a
/private/) -- Matthias
27 matches
Mail list logo
