Ah, the lament of the functional ascetic lol https://www.theregister.co.uk/2017/05/31/at_the_feet_of_the_great_monad/

I can't even figure out what's going on here

i think its trying to say look down on others based on what language they use

yeah, it isn’t reserved only for FPers, unfortunately. You see the same attitude when people look down on php devs. Or ruby ppl looking down on everyone else, etc.

With some typically self deprecating british humor on top

I love Verity Stob… so funny!

never read this author before. clicking on the name to get a list of other articles. This one didn't seem to hit the mark with me but I'd like to read some others

If you didn’t find this hilarious, you might not be moved by other Stob pieces either… It’s a somewhat peculiarly British style of humor :uk:

It's amusing, but the effectiveness of the caricature is a bit dampened by how token some of the descriptive parts are, instead of feeling naturally woven in. ¯\(ツ)/¯

Aphyr's - while a bit more whimsical and filled with technical witchery - felt much sharper for that kind of satire.

To me, Aphyr’s is too bogged down with technical cleverness to be effective. Humor is cultural/subjective tho’…

hmm, yeah, I don’t find british humor funny. 😕

Imbibe deeply of Pratchett, and you might find your preferences shifting 🙂

I thought it quite funny. I liked the twist at the end. Went from futuristic to Me in Exeter a couple years ago 😛

It's definitely inspired by the opening chapter of Brave New World

@mobileink Lazy eval is like a synthetic thread, on top of real threads, that only loops on one function, which is the realization of next element. So perhaps it's about distinguishing between regular eval on (inc 1), which will eval eagerly, and the looping eval that runs on a LazySeq.

hmm. i'm not convinced we need to introduce threads. any computation has an evaluation strategy.

to me strict eval means "reduce to normal form".

I just mean the base event loop. Which is eager. LazySeqs create sub event loops.

what events? assume we are in a single-threaded env.

Right, CLJS, for instance.

JS has an event loop.

yeah, but that's orthogonal to strict/lazy.

Well, lazy evaluation in CLJS is a looping construct that repeatedly calls one function on a data structure.

In Haskell, evaluation is demand-based. When an answer is demanded, a function gets called. In Clojure when you call a function it happens immediately, regardless of demand.

jit eval

?

just in time evaluation

more terminology isn't helping... =(

on-demand = just in time.

Right. eval in CLJ/CLJS is not JIT/On demand

to me it's more about how far rather than when. with strict eval you get reduction to normal form. with lazy you might get bo reduction or partial deduction, to be completed later.

i think the JIT vs just in time evaluation is confusing and that's why ghadi said more terminology is not required. at this point its not clear if you mean the fact that jvm code is interpreted or the delayed evaluation of the thunks in a seq

@john huh? taking from an inifinite list?

But in clojure, only specific functions will actually do the necessary iteration on the structure in order to realize each next.

like into

right. but that's a language feature: lazy eval.

It's more of a feature of into and LazySeq, together, but not necessarily other things.

ok. the lazy eval feature of certain forms is defined by the language.

laziness need not be all or nothing.

it is a feature of clojure that some evals, but not all, are lazy.

You could implement it in mostly languages though, probably.

If you go read the LazySeq code, you'll see how it realizes the sequence. It's pretty simple.

indeed, presumably in any kanguage.

But in a "lazy language," like haskell, internal forms aren't realized unless they are needed. Whereas in clojure, they are realized immediately.

"realized"?

(def a (+ 1 2)) my understanding is that in Haskell, a wouldn't not become 3 until a was called in some other eager context.

(repeat 5)

right. with strict eval, the arg will be fully reduced to 3. you can't do that with (repeat 5) etc.

i don't see the logic of saying that things like (repeat 5) are strictly evaluated in clojure.

it makes no sense to me.

Repeat immediately returns you a data structure

ugh

sure. on that can later be evaled.

returns a cljs.core/LazySeq in the repl

No, it's already evaluated. The fact that it is a sequence that hasn't been fully realized yet is besides the point

but you cannot reduce (repeat 5) to a normal form. all you can do is translate it into a fn the will return the right vals when called later. to me that is what counts as lazy eval.

You're thinking in terms of Haskell again

Which is fine, but it's not helping understand

There's no reduction phase here

It might be better to think of lazy structures as just functions that close over state and call themselves.

no, i'm thinking of evaluation strategies. after all, haskell is exactly like clojure in this respect, afaics.

You call a function and it immediately returns a structure

no reduction = lazy eval.

If you look up Clojure and Haskell in Wikipedia, they use different evaluation strategies. I'm trying to illustrate why

in the end the whole point is reduction to normal form.

Clojure is exactly like Java and Python in this respect

java has language-level infinite lists?

What does language level mean

Clojure's are in a library, not the language

the language supports it out of the box, you don't have to implement it yourself.

It happens to be the core library, but it's a lib nonethelrss

here's the java implementation:

final synchronized public ISeq seq(){
	sval();
	if(sv != null)
		{
		Object ls = sv;
		sv = null;
		while(ls instanceof LazySeq)
			{
			ls = ((LazySeq)ls).sval();
			}
		s = RT.seq(ls);
		}
	return s;
}

final synchronized Object sval(){
	if(fn != null)
		{
                sv = fn.invoke();
                fn = null;
		}
	if(sv != null)
		return sv;
	return s;
}

infinite sequences in java

@ghadi wait, you're saying lazy stuff is not part of the definition of clojure?

here's one in C#: Enumerable.Range(0);

It's defined on the clojure side, per say.

Yeah it's not baked into the compiler, it's in userspace

@dpsutton yes, of course, you can implement it in any language.

so all languages are lazy?

no.

that's not close to what any common usage of a "lazy language" adjective could mean then

i think we have an ill-defined concept then

you can write a lazy lib (infinite seqs etc.) in any language.. that's different.

i think we all agree with that

Yup

and the fact that rich hickey did it doesn't change the semantics of clojure

or scheme

or c#

or java

ok. who said it did? semantics is a separate issue.

the original question is whether clojure has lazy eval, as a feature of the language.

LazySeqs and a collection of associated functions have lazy eval. And that part of clojure is "lazy"

Unlike Haskell, right?

@ghadi: aha. is that why you say clojure eval is always strict? that would make sense, if you mean that the lazy stuff is a kind of add on. but i'm inclined to treat it as in practuce a part of the language defn.

In Haskell, it's more like there are a handful of functions for doing eager eval

still, that would be a good topic for some doc. my guess is pretty much everybody thinks lazy seqs involve lazy evaluation.

which they do, but whether that is a language feature is a separate question.

Perhaps a better word would be lazy iteration

Eval is eager, while iteration is optionally lazy, where many core abstractions opt in.

But usually also support eager.

Well said

From the perspective of both a Clojurian and a Haskeller, I think you all have some good points. The confusion seems to stem from the fact that the distinction between compiler-level and userland is a bit blurred in Clojure

i think the idea that the core language uses strict eval, while the "std lib" implements restricted forms of lazy eval, is pretty interesting. and show off the power and flexibity of clojure.

compare the definition of C. it defines the language, but also the std libs.

but the lib features do not really define the language.

@ghadi thanks so much for engaging. i think i have an idea of what you mean now, and my grasp of the language has expanded.

:thumbsup: awesome

worth looking into the sources. lazy-seq is defined as

(defmacro lazy-seq
  [& body]
  (list 'new 'clojure.lang.LazySeq (list* '^{:once true} fn* [] body)))    

It's harder to explain stuff when someone has an advanced knowledge of things sometimes. @mobileink

Clojure's​ evaluation is pretty ordinary

When you call a function, it gives you flesh. In Haskell when you call a function it gives you a thought about flesh

😆

Reminds me of a chain of promises.

more likely futures, but that is exactly what's going on

omg! the metaphysical cafe! it's in an early mamet play. the menu includes things like "idea of lamb, soupcon of asparagus, notion of beef stroganoff". 😂

the play is "squirrels". very funny.

there's also call-by-need, which gives you either a thought of flesh or thaws out a steak from the freezer if available 😄

i'm looking for the eval strategy that will do my laundry.

System/gc?

i'll take that.

Do you think that if I write a spec that requires that the value is a vector and it is sorted, and I use clojure.test.check.generators/generate with that spec, it will be able to generate sorted vectors in a Bogosort fashion?

https://en.wikipedia.org/wiki/Bogosort

100% serious about this.

This could be used as a sorting function by requiring that every element of the vector is an element of an input vector, or something