On Dec 7, 4:10 pm, Christophe Grand <[EMAIL PROTECTED]> wrote:
> Rich Hickey a écrit :> I think the problem is that in the original and
> subsequent versions,
> > work was being done in the current case that needn't be (checking the
> > status of coll), and that we need more laziness than lazy-cons gives
> > us (we need to delay evaluation of one argument to the recursive
> > call). delay/force offer laziness a la carte
>
> Thanks Rich! I wasn't aware that (force x) returns x if x is not a
> Delay, this is good to know. (I assume that having seq to automatically
> force its argument would be a perf killer.)
It's less the perf than that it is a different model, e.g. (delay nil)
is logical true. Using delays internally is one thing, but were they
to leak out, it would break the seq/no-seq(nil) model, and instead
require all use of seqs to force or be wrapped in macros that do the
forcing. I'm not saying that's wrong, but I thought it would be more
cumbersome than the current model which abstracts CL's cons cells.
In practice, we've ended up with more calls to seq than I envisioned,
mostly to allow fns to work with anything seq-able, so must seq on
entry, but there are still plenty of places where it is convenient not
to have to call seq, and directly test the sequence in conditionals,
and few where not having seqs be universally (potentially) delayed is
a hindrance.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
