Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An apologia of lazy evaluation

epicandmonicisnotiso.blogspot.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: An apologia of lazy evaluation

#31

Post by noloblo »

one-punch wrote: post #10
wirrbel wrote: post #6

Earlier quoted context omitted.

I really wished there was a GC-ed but strictly-evaluating Haskell. A Rust-like syntax would probably help with adoption but I don't have a strong preference in that.

> I really wished there was a GC-ed but strictly-evaluating Haskell. To answer this question literally, there are PureScript (transpile to JavaScript), Idris (dependently typed), OCaml, and Standard ML (as discarded1023 pointed out). But I think the wish for a strictly-evaluating Haskell is sometimes in fact a wish for a Haskell with more predictable performance (especially in memory usage). If so, the Linear Type/Ar…

And faster Compile times haskell compile times relative to golang are super slow

Re: An apologia of lazy evaluation

#32

Post by murdoze »

throwaway81523 wrote: post #13
ummonk wrote: post #8

The article seems to downplay the effect that space leaks can have on correctness / reliability. If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. You can no longer rely on any program you write being guaranteed to execute to completion.

I would say in an exaggerated version of the Haskell mindset, the most important thing is to prevent the program from giving wrong answers. The archetypal Haskell program is a compiler, and having it generate wrong code that gets deployed on a space mission is disastrous. Having the compiler crash with a memory leak is merely an annoyance. You would not write realtime code in idiomatic Haskell, if you would write suc…

Real-time code has high requirements for correctness and execution deadlines.

Which means, w/o deterministic execution Haskell not suitable for a whole niche, where its safety properties are in a high demand. Which is a pity.

Re: An apologia of lazy evaluation

#33

Post by lispm »

antonvs wrote: post #28
lispm wrote: post #16

Earlier quoted context omitted.

There are some Lisp communities which value syntactic extensibility more than low-level performance. For example when using FEXPRs, which are functions which have access to their source and where the function decides which arguments to evaluate. You'll find that in R, Picolisp, Standard Lisp and a few others. Most other Lisp communities have settled on always strict evaluation and compilable macros as syntactic exten…

FEXPRs haven’t been relevant in mainstream Lisp since the 1980s. See Kent Pitman’s 1980 article describing the problems with them: https://www.nhplace.com/kent/Papers/Special-Forms.htmL The languages you mention probably use them mainly because they’re easy to implement in the language implementation, which has nothing to do with what the community values, except in a post-hoc sense when the community tries to justif…

Usually the arguments are a) it provides runtime access to the source (which for example is useful in R), b) runtime introspection is easier to understand (for the proponents) & less complex than macros and that macros are too static (they want more flexibility at runtime). For example authors of the REDUCE computer algebra system ( https://reduce-algebra.sourceforge.io/ ) disliked Common Lisp for the lack of FEXPRs and that's why they stayed away from it. There were lots of discussions at the time when Common Lisp was introduced.

> The languages you mention probably

No, see above.

Example: https://picolisp.com/wiki/?pros-and-cons

Re: An apologia of lazy evaluation

#34

Post by hexane360 »

murdoze wrote: post #32
throwaway81523 wrote: post #13

Earlier quoted context omitted.

I would say in an exaggerated version of the Haskell mindset, the most important thing is to prevent the program from giving wrong answers. The archetypal Haskell program is a compiler, and having it generate wrong code that gets deployed on a space mission is disastrous. Having the compiler crash with a memory leak is merely an annoyance. You would not write realtime code in idiomatic Haskell, if you would write suc…

Real-time code has high requirements for correctness and execution deadlines. Which means, w/o deterministic execution Haskell not suitable for a whole niche, where its safety properties are in a high demand. Which is a pity.

Sure, but currently almost all of the most popular languages are also not suitable for that niche.

If you exclude any garbage-collected language, you're basically left with Ada, C, C++, some of the "C/C++ successors" (Zig, D, Carbon, maybe Nim), and Rust.

Re: An apologia of lazy evaluation

#35

Post by one-punch »

noloblo wrote: post #31
one-punch wrote: post #10

Earlier quoted context omitted.

> I really wished there was a GC-ed but strictly-evaluating Haskell. To answer this question literally, there are PureScript (transpile to JavaScript), Idris (dependently typed), OCaml, and Standard ML (as discarded1023 pointed out). But I think the wish for a strictly-evaluating Haskell is sometimes in fact a wish for a Haskell with more predictable performance (especially in memory usage). If so, the Linear Type/Ar…

And faster Compile times haskell compile times relative to golang are super slow

Golang prioritizes compile time (hence it took them so long to get Generics), which Rust and Haskell are unlikely to beat, as they both prioritize high-levels of abstractions (more compile time for zero cost abstractions at runtime).

That said, since GHC is implemented in Haskell, the compile time will likely improve if linear type/arrow, or a better runtime (such as optimal reductions), is used by GHC itself.

Re: An apologia of lazy evaluation

#36

Post by bmitc »

wirrbel wrote: post #26
bmitc wrote: post #17

Earlier quoted context omitted.

My preference are ML dialects, but it sounds like Idris is something you should check out. It's strict by default and has type classes and dependent types.

Idris was always filed in my head as some estoric/academic/obscure thing, will have a look at it.

I actually think it's probably less academic than Haskell or Racket. It's intended to be a practical language that people build things with. It just has an advanced type system and a small community.

Re: An apologia of lazy evaluation

#37

Post by ummonk »

chriswarbo wrote: post #20
ummonk wrote: post #8

The article seems to downplay the effect that space leaks can have on correctness / reliability. If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. You can no longer rely on any program you write being guaranteed to execute to completion.

> If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. I don't know what you mean by "nondeterministic"? The behavious is occasionally hard to predict , but it's completely deterministic. Compare it to e.g. writing C in a certain style, relying on GCC to optimise it. Those optimisations might no…

I should have said "undefined". What I meant was that the space the program will use isn't defined by the language itself and can't be known at compile time. It's dependent on implementation details of the compiler (GHC), and the particular input you feed to the program when executing it.

Re: An apologia of lazy evaluation

#38

Post by runeks »

ummonk wrote: post #37
chriswarbo wrote: post #20

Earlier quoted context omitted.

> If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. I don't know what you mean by "nondeterministic"? The behavious is occasionally hard to predict , but it's completely deterministic. Compare it to e.g. writing C in a certain style, relying on GCC to optimise it. Those optimisations might no…

I should have said "undefined". What I meant was that the space the program will use isn't defined by the language itself and can't be known at compile time. It's dependent on implementation details of the compiler (GHC), and the particular input you feed to the program when executing it.

> What I meant was that the space the program will use isn't defined by the language itself and can't be known at compile time.

You can know the space usage (in relation to input size) of some Haskell programs at compile-time — e.g. if you use a constant-memory streaming abstraction.

I don’t know much about Rust, but I don’t think it guarantees known space usage of all possible programs at compile-time.

Re: An apologia of lazy evaluation

#39

Post by slacknatcher12 »

dan-robertson wrote: post #29

I was surprised by the argument about the distribution of space leaks. In particular, it feels a lot like the kinds of silly arguments C/C++ people make about various safety features – that bugs are unlikely / easy to catch / only made by the inexperienced. Those arguments are silly[1] because evidence from the C/C++ programmers who try hard to write correct programs that avoid these bugs is that they cannot be total…

Hi Author here

> Perhaps it is true that worries about space leaks or surprising performance are overblown. But I think that any apology for lazy evaluation in Haskell should attempt to understand and argue against the reasons that someone like SPJ would say ‘the next Haskell will be strict’. (I’m not totally sure what the reason is; maybe it’s just that lazy evaluation is unpopular)

You are completely right. The type (b) of space leaks that are a correctness concern must be addressed. I was intending to do a second post about it.

I have a classification of space leaks that gives rise to defensive patterns to avoid the class (b). In general space leaks come in two varieties:

- Strictness space leaks: there is thunk that to be evaluated need to enter another thunk and another and another, usually growing in size. If we had evaluated in the reduction we could have collapsed the layers accordingly. The classic "foldl' vs foldl" leak is of this kind.

- Liveness space leaks: There is a reference that is kept alive because is needed to evaluate a thunk. If we force the thunk, that reference is marked dead and collected.

Type 1 of leaks are a property of functions with recursive calls or functions are that are binding expressions (such as >>=). They are local property leak. Type 2 are a global property and the more common kind. Obviously seq appropriately on a strict monad solves the issue. I will do another blogpost discussing the defensive patterns.

Re: An apologia of lazy evaluation

#40

Post by throwaway81523 »

murdoze wrote: post #32
throwaway81523 wrote: post #13

Earlier quoted context omitted.

I would say in an exaggerated version of the Haskell mindset, the most important thing is to prevent the program from giving wrong answers. The archetypal Haskell program is a compiler, and having it generate wrong code that gets deployed on a space mission is disastrous. Having the compiler crash with a memory leak is merely an annoyance. You would not write realtime code in idiomatic Haskell, if you would write suc…

Real-time code has high requirements for correctness and execution deadlines. Which means, w/o deterministic execution Haskell not suitable for a whole niche, where its safety properties are in a high demand. Which is a pity.

That's fine, those applications are why Ada was invented. Languages get pulled in too many directions when they try to be everything to everyone.
Post reply on HN