On Jan 18, 5:17 am, Mark Engelberg wrote:
> On Fri, Jan 9, 2009 at 6:00 AM, Rich Hickey wrote:
> > When I hadlazy-seqin play, many of those were defined that way. The
> > real cost is explaining either whylazy-seqis private, or, if public,
> > when/how to use it.
>
> I'd certainly make use ofl
On Fri, Jan 9, 2009 at 6:00 AM, Rich Hickey wrote:
> When I had lazy-seq in play, many of those were defined that way. The
> real cost is explaining either why lazy-seq is private, or, if public,
> when/how to use it.
I'd certainly make use of lazy-seq if it were public. But assuming
it's not m
>From my limited understanding it seems that a lazy data structure must
at some point reify and therefore be cached, to my mind, the
alternative is better describes as a stream or generator.
That is not to say that said stream is not the source of the
reification but that it might be better to k
Thanks Rich. I definitely appreciate the fuller explanation. It
helped me understand what you've already tried, and what factors led
to your design decision. You've given me a lot to think about.
--~--~-~--~~~---~--~~
You received this message because you are su
On Jan 9, 6:05 am, Timothy Pratley wrote:
> Rich: You make the distinction that streams are not non-caching seqs.
> I read this as meaning that they wont implement ISeq, they will
> implement IStream, but conceptually they would be a non-caching
> "sequence" (in the English phrase sense, as opp
On Jan 9, 12:50 am, "Mark Engelberg" wrote:
> Oh, I mentioned this in my blog post, but perhaps it bears repating.
> If cycle, repeat, and replicate were implemented behind-the-scenes
> with LazySeq as opposed to LazyCons, they would still implement the
> promise of identical elements for separ
On Jan 8, 11:22 pm, "Mark Engelberg" wrote:
> On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey wrote:
> > When you
> > ask for the nth element/rest, you get the identical item every time.
>
> I know this is nitpicking, but if this is really the promise that the
> seq abstraction is supposed to fulf
Rich: You make the distinction that streams are not non-caching seqs.
I read this as meaning that they wont implement ISeq, they will
implement IStream, but conceptually they would be a non-caching
"sequence" (in the English phrase sense, as opposed to seq in the
interface sense), and they should
Oh, I mentioned this in my blog post, but perhaps it bears repating.
If cycle, repeat, and replicate were implemented behind-the-scenes
with LazySeq as opposed to LazyCons, they would still implement the
promise of identical elements for separate traversals, but would be
more efficient. Also, ran
On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey wrote:
> When you
> ask for the nth element/rest, you get the identical item every time.
I know this is nitpicking, but if this is really the promise that the
seq abstraction is supposed to fulfill, then Clojure already violates
this:
(def a (seq [1 2
If streams are not a breaking change, my vote is to ship 1.0 and then
add them.
Stuart
> I've been holding off on integrating this as it is a fairly
> substantial change (under the hood, no change at all for consumers),
> introduces a new abstraction (though no impact until you use it), and
>
I'd vote for increased priority to reaching 1.0 also because of
workplace constraints.
Kev
On Jan 9, 4:23 am, MikeM wrote:
> > Do people want it now?
>
> I would vote for 1.0 ahead of streams if adding streams now will delay
> 1.0.
--~--~-~--~~~---~--~~
You recei
On Thu, Jan 8, 2009 at 10:20 AM, Rich Hickey wrote:
> On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey
> I think the real test of non-cached seqs is to swap them in for
> regular seqs, rebuild Clojure and some user libs and see what breaks
> and why. Then you'll see the dependencies on caching that e
On Jan 8, 2009, at 1:06 PM, Mark Engelberg wrote:
>
> On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey
> wrote:
>> The
>> promise of the abstraction is not merely that the nth item/rest will
>> be equal - it is that it will be identical. I.e. a seq is persistent
>> and immutable.
>
> I get that Cl
On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey wrote:
> The
> promise of the abstraction is not merely that the nth item/rest will
> be equal - it is that it will be identical. I.e. a seq is persistent
> and immutable.
I get that Clojure is making a promise of identity here, which is not
possible i
Mark, I thought your blog post was really, really good. I have
forwarded it to a lot of people; I hope you don't mind!
As far as caching goes:
I think, regardless of the theoretical considerations of = that
caching a lot of objects is ridiculous from a performance
perspective. Access to ram ta
>
> Do people want it now?
>
I would vote for 1.0 ahead of streams if adding streams now will delay
1.0.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@
On Jan 8, 2009, at 8:55 AM, Rich Hickey wrote:
>
>
>
> On Jan 8, 7:26 am, Konrad Hinsen wrote:
>> On 08.01.2009, at 11:22, Mark Engelberg wrote:
>>
>>> So my blog post has a dual purpose. First, I explain the "gotcha"
>>> that Stuart and I discussed. Second, I report back to the community
>
On 08.01.2009, at 14:55, Rich Hickey wrote:
> difference to the consumers of your sequence" is simply untrue. The
> promise of the abstraction is not merely that the nth item/rest will
> be equal - it is that it will be identical. I.e. a seq is persistent
> and immutable. There's nothing wrong wi
On Jan 8, 7:26 am, Konrad Hinsen wrote:
> On 08.01.2009, at 11:22, Mark Engelberg wrote:
>
> > So my blog post has a dual purpose. First, I explain the "gotcha"
> > that Stuart and I discussed. Second, I report back to the community
> > about the actual experience I had in the past month, exp
On 08.01.2009, at 11:22, Mark Engelberg wrote:
> So my blog post has a dual purpose. First, I explain the "gotcha"
> that Stuart and I discussed. Second, I report back to the community
> about the actual experience I had in the past month, exploring
> laziness in Clojure. I decided to blog it
A few days ago, Stuart Halloway and I had an offline discussion about
some of the "gotchas" related to Clojure's laziness. He encouraged me
to blog about my thoughts on the matter.
On a related note, about a month ago, I posted comments about
Clojure's laziness. Rich's response was:
"The argum
22 matches
Mail list logo
