Re: Lazy evaluation of arguments

chael Griffiths wrote: >>> >>> I'm not sure I fully understand your proposal, but when I really need >>> lazy evaluation (which is pretty rare) I reach for `delay` and `force`. >>> >>> On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote: >>>&

Re: Lazy evaluation of arguments

lock in case of failure >> >> >> On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote: >>> >>> I'm not sure I fully understand your proposal, but when I really need >>> lazy evaluation (which is pretty rare) I reach for `delay` and `forc

Re: Lazy evaluation of arguments

e of failure > > > On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote: >> >> I'm not sure I fully understand your proposal, but when I really need >> lazy evaluation (which is pretty rare) I reach for `delay` and `force`. >> >> On Tuesda

Re: Lazy evaluation of arguments

@onsucess ; deref block in case of success @onfailure)) ; deref block in case of failure On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote: > > I'm not sure I fully understand your proposal, but when I really need lazy > evaluation (which is pretty rar

Re: Lazy evaluation of arguments

I'm not sure I fully understand your proposal, but when I really need lazy evaluation (which is pretty rare) I reach for `delay` and `force`. On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote: > > Hi! > > In short: > > I have noticed that in most cases I use macros

Lazy evaluation of arguments

Hi! In short: I have noticed that in most cases I use macros only for lazy arguments evaluation. Why not to make something to use only this feature? It would be light version of macro for clojurescript/clojure and easy to grasp for newcomers and still powerful in programming (with that you cou

Re: core.async -- lazy evaluation on take

On Monday, February 16, 2015 at 9:42:31 PM UTC-5, Erik Price wrote: > > Yes, the producer’s put will block until the consumer takes, but doesn’t > this still involve an eager initial request (so that the producer will have > something to put in the first place, so that it can block)? > The produc

Re: core.async -- lazy evaluation on take

Yes, the producer’s put will block until the consumer takes, but doesn’t this still involve an eager initial request (so that the producer will have something to put in the first place, so that it can block)? e ​ On Mon, Feb 16, 2015 at 5:52 PM, wrote: > Make the channel unbuffered, that way it

Re: core.async -- lazy evaluation on take

Make the channel unbuffered, that way it turns into a rondevouz a la ada and every producer will block until a consumer takes something from it. cheers Jan > On 16.02.2015, at 21:45, Huey Petersen wrote: > > Hello, > > I was playing around with having a lazy sequence abstracting over a paged

core.async -- lazy evaluation on take

Hello, I was playing around with having a lazy sequence abstracting over a paged http request. First off, maybe this is dumb, I dunno, lemme know ;p So (resources "url") returns a seq and no http request is made, but (take 1 (resources "url")) makes a request and (take 50 (resources "url")) ma

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

True, but I think that's why he argues for a strict language which controls side effects via monads, as Haskell does. On 9 July 2014 07:18, Magnus Therning wrote: > On Tue, Jul 08, 2014 at 08:39:30PM +0200, Colin Fleming wrote: > > I searched for this as well, and found this: > > http://www.cs.

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

On Tue, Jul 08, 2014 at 08:39:30PM +0200, Colin Fleming wrote: > I searched for this as well, and found this: > http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt > > "Purity is more important than, and quite independent of, laziness" > > and > > "The next ML will be pure, with effects

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

l pure." On 8 July 2014 19:58, Andrey Antukh wrote: > 2014-07-08 18:20 GMT+02:00 Marko Kocić : > > Clojure doesn't have lazy evaluation because it is a "few" years younger >> and didn't want to repeat Haskell's mistake. Even Simon Payton Jones, the &

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

2014-07-08 18:20 GMT+02:00 Marko Kocić : > Clojure doesn't have lazy evaluation because it is a "few" years younger > and didn't want to repeat Haskell's mistake. Even Simon Payton Jones, the > creator of Haskel, confessed that, if he would make Haskel again,

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

Clojure doesn't have lazy evaluation because it is a "few" years younger and didn't want to repeat Haskell's mistake. Even Simon Payton Jones, the creator of Haskel, confessed that, if he would make Haskel again, he would make it strict, and not lazy, but that i

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

o relevant to the present controversy over lazy > evaluation. > Some believe that functional languages should be lazy; others believe they > should not. Some compromise and provide only lazy lists, with a special > syntax > for constructing them (as, for example, in Scheme [1]). This paper pro

Re: Why clojure does not have pure lazy-evaluation like Haskell ?

also relevant to the present controversy over lazy > evaluation. > Some believe that functional languages should be lazy; others believe they > should not. Some compromise and provide only lazy lists, with a special > syntax > for constructing them (as, for example, in Scheme

Why clojure does not have pure lazy-evaluation like Haskell ?

I am new to clojure and finding it great.. :) I came across a paper - Why functional programming matters ? at www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf to quote it : "This paper is also relevant to the present controversy over lazy evaluation. Some believe that funct

Re: Lazy evaluation

be performance benefits from >>> keeping those intermediate results in a processor's cache while doing f1, >>> f2, f3, etc., rather than a whole pass of applying f1, then going back to >>> the beginning and doing a whole pass of f2, etc. This is primarily an >>&g

Re: Lazy evaluation

e large enough that they do not fit into the >> cache. >> >> Andy >> >> >> >> On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi >> >> > wrote: >> >>> I am just a newbie who has been hanging around and it is rather late in &

Re: Lazy evaluation

gt; > On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi wrote: > >> I am just a newbie who has been hanging around and it is rather late in >> the day to bring this up but... >> >> should we remove lazy sequences and lazy evaluation from Clojure? Back >> of the enve

Re: Lazy evaluation

but... > > should we remove lazy sequences and lazy evaluation from Clojure? Back of > the envelope calculations show that we can get 2x performance improvements. > > Thanks, > Pradip > > -- > You received this message because you are subscribed to the Google > Gr

Lazy evaluation

I am just a newbie who has been hanging around and it is rather late in the day to bring this up but... should we remove lazy sequences and lazy evaluation from Clojure? Back of the envelope calculations show that we can get 2x performance improvements. Thanks, Pradip -- You received this

Re: Question about lazy evaluation

Hi Jeremy, The 'find in collection' function is 'filter', so one way to write find the first match would be like: user=> (first (filter (partial = 25) (iterate inc 20))) 25 Filter is lazy itself so in this example I believe minimum execution is forced. Regarding yo

Question about lazy evaluation

I have this very trivial function: (defn find-me [n] (loop [coll (iterate inc 20)] (if (= (first coll) n) n (recur (next coll) Let's leave out the problem that the loop may never end. My question is the sequence that's bound to coll in the loop will only generate the next digit in