> > Put another way: why does apply need to promise not to realize its seq
> > argument?
>
> (apply + some-lazy-seq-too-big-to-fit-in-main-memory)
>
> Not "avoid evaluating some of its arguments" but "avoid holding onto
> the head" in that case.
>
I'd reach for 'reduce' in this case but that's st
On Wed, Mar 28, 2012 at 7:16 PM, Timothy Baldridge wrote:
> "May be delayed"
>
> But I don't think they ever are:
>
> user=> (def oddseq (map #(do (print %) %) (range 30)))
> #'user/oddseq
>
> user=> (defn foo [& args] 'd)
> #'user/foo
>
> user=> (apply foo oddseq)
> 012345678910111213141516171819
On Wed, Mar 28, 2012 at 8:32 PM, Nathan Sorenson wrote:
>
>> I don't think it's possible to ever have apply not evaluate all its
>> arguments? I think this is what Nathan was saying.
>
> Cedric is right that apply, itself, is strict and evaluates its arguments as
> one might expect. But I'm not re
An example of "lazy" apply, with your foo fn:
> (apply foo (iterate inc 0))
d
--
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
Note that posts from new members are moderated - please be pat
> I don't think it's possible to ever have apply not evaluate all its
> arguments? I think this is what Nathan was saying.
>
Cedric is right that apply, itself, is strict and evaluates its arguments
as one might expect. But I'm not referring to manual thunking/delaying your
arguments to mimic
"May be delayed"
But I don't think they ever are:
user=> (def oddseq (map #(do (print %) %) (range 30)))
#'user/oddseq
user=> (defn foo [& args] 'd)
#'user/foo
user=> (apply foo oddseq)
01234567891011121314151617181920212223242526272829d
user=> (def oddseq (map #(do (print %) %) (range 1)))
#'
On Wed, Mar 28, 2012 at 2:13 PM, Timothy Baldridge wrote:
>>>is there a use case behind apply being lazy when Clojure is otherwise a
>>>strictly evaluating language
>
> In clojure-py we have to pass vararg arguments as tuples. So it ends
> up a lot like
>
> (to-tuple (concat args seqarg))
>
> I a
>>is there a use case behind apply being lazy when Clojure is otherwise a
>>strictly evaluating language
In clojure-py we have to pass vararg arguments as tuples. So it ends
up a lot like
(to-tuple (concat args seqarg))
I always saw the seq argument in IFn as a crutch to get around the "we
have
Actually now that I've thought about it, you couldn't mimic non-strict
evaluation with lazy apply, so that's not a use-case. All you could provide
is left-to-right argument non-strictness which is not sufficient. W.r.t.
your example, you can force evaluation the first 3 args, but you can't,
sa
Your right the core apply is lazy too. The same question still remains: is
there a use case behind apply being lazy when Clojure is otherwise a
strictly evaluating language? Perhaps is this the intended mechanism to
smuggle non-strictness into evaluation?
--
You received this message because y
On Mar 27, 11:51 pm, Nathan Sorenson wrote:
> When trawling the ClojureScript source, I was a little puzzled when I first
> noticed that cljs.core/apply respects the laziness of the seq its provided.
> Fogus mentioned this feature in his Clojure/west talk and it reminded me of
> my earlier puzzlem
When trawling the ClojureScript source, I was a little puzzled when I first
noticed that cljs.core/apply respects the laziness of the seq its provided.
Fogus mentioned this feature in his Clojure/west talk and it reminded me of
my earlier puzzlement.
This choice seems to contradict Clojure's ea
12 matches
Mail list logo
