Hacker News Reader

Comment by dexwiz | Hacker News Reader

It uses Javascript in the examples, but Javascript has slightly different definitions for some.

Partial Application and .bind(). Function.bind() in JS is about setting `this` for when the function is called[1].

Constant, `const`, declaration in JS governs reference reassignment. Is that the same as referential transparency? Either way the example is wrong. The following is not an invariant. `five` cannot be changed, but `john.age` can be. The object reference is constant, but not the object value.

`john.age + five === ({name: 'John', age: 30}).age + (5)`

Lazy evaluation should be called a generator if we are doing JS specific naming conventions.[2] Seems like the Haskell camp like the term Lazy Evaluation, but the Pythonthoic yield camp likes the term Generator.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

View on HN

> Lazy evaluation should be called a generator if we are doing JS specific naming conventions.

The two are actually orthogonal -- generators are a control-flow structure where control keeps re-entering an existing function context and returning from it (basically, a coroutine), whereas lazy evaluation is a language-semantics choice where every value starts out as a thunk (bit of code) with enough information to compute the value, until resolved to the result.

Generators in the Python or JavaScript sense aren't really doing "lazy evaluation" in the Haskell sense, IMHO, though I can see how one sees the parallels (infinite sequences, etc). You can have the same "infinite sequence" by just defining an iterator implementation that always returns a next value, without the use of generators/coroutines.

Likewise, there are other uses for lazy evaluation than generator-like infinite sequences. For example, lazy evaluation lets you build a (finite) table of values in a memoized dynamic-programming problem, where each value is an expression that refers to some of the other values, and the lazy evaluation semantics ensure that (i) only the needed values are computed and (ii) once a value is computed, it's memoized (the thunk resolves to its result). You get demand-based computation and memoization "for free" from the language runtime.

>Partial Application and .bind(). Function.bind() in JS is about setting `this` for when the function is called

Everything after the first parameter to .bind() sets regular parameters.

>Lazy evaluation should be called a generator if we are doing JS specific naming conventions.

They used a generator as an example of lazy evaluation. Not all generators are examples of lazy evaluation, and not all lazy evaluation is done with generators.

Agreed about const. In Javascript, const is purely about the variable binding being immutable, and not a statement about the value itself.

> Everything after the first parameter to .bind() sets regular parameters.

And if you consider `this` to be an implicit first parameter, everything makes perfect sense.

`this` isn't exactly like a parameter to .bind() though: the `this` value passed to the bound function is completely ignored, instead of being passed as extra arguments.

Generator is a specific algorithm that emulates a kind of lazy evaluation in strict languages.

Reply on news.ycombinator.com