On Jan 8, 2009, at 8:55 AM, Rich Hickey <richhic...@gmail.com> wrote:
>
>
>
> On Jan 8, 7:26 am, Konrad Hinsen <konrad.hin...@laposte.net> 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, exploring
>>> laziness in Clojure. I decided to blog it rather than post it here
>>> primarily due to its length.
>>
>> An interesting analysis. Looking my own applications, I tend to agree
>> with your observations, but then I also have a similar code base as
>> you have: almost all of it is purely functional code using Clojure's
>> basic data structures.
>>
>> I also agree with your conclusion that the critical point is lazy
>> sequences whose constructors are not referentially transparent. I
>> wonder if there is any way to have them detected reliably (at compile
>> time or at run time), but I expect this can't be done. Another
>> solution would be to detect lazy sequences guaranteed to be purely
>> functional because of the exclusive use of safe functions, and make
>> them uncached by default. That should be doable but perhaps with an
>> unreasonable effort or a high runtime penalty.
>>
>
> The sequence abstraction in Clojure is the list abstraction of Lisp.
> No more, no less. It is inherently a persistent abstraction. When you
> ask for the nth element/rest, you get the identical item every time.
> All laziness adds is the fact that rest might not exist until you ask
> for it. Once you do, it's a Lisp list. It doesn't matter whether it
> originally came from an ephemeral source or a long-running calculation
> or whatever. The claim "So the amazing thing is that whether you
> choose to build a cached or uncached sequence, it makes not one bit of
> 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 with Lisp's list abstraction nor
> its realization as seqs in Clojure.
>
> Making seqs 'non-caching' makes no sense because they are no longer
> the same abstraction. Lazy != ephemeral. Seqs and streams are
> different abstractions.
>
> The questions really are, is there room for additional, ephemeral,
> abstraction - streams, and can filter/map et al be freed from working
> only with the seq abstraction. I've said yes to both of these and have
> a working solution that supports transparent interoperation of seqs
> and streams, thread safety, and single-source algorithm definition for
> both uses. It is not based on non-caching seqs.
>
> 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
> might delay 1.0.
>
> Do people want it now?
I'd use it now. If it's more important to get 1.0 out, I'd happily
wait until 1.1.
>
>
> Rich
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
