An apologia of lazy evaluation • Hacker News Board

Re: An apologia of lazy evaluation

#51

Post by shirogane86x » Mon, Mar 27, 2023, 8:11 AM UTC

bmitc wrote: post #19

sfvisser wrote: post #2

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition. In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out. In Haskell you don’t really do that. If…

> Like the article explains, laziness is a big part of this. I don't think the article does a good job addressing this. They have a conclusion they want to get to, but I don't see how they get there with the arguments provided. Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more…

As someone who worked with F# professionally for multiple years, I think I can quite confidently say that laziness is not ergonomic in F#, at all. I've tried making use of it many times, but because you have to explicitly delay and force values all over the place, it infects and dirties up code whenever you try to use it.

Idris(at least idris2) gets a bit closer with the implicit delaying and forcing, but changing a value from lazy to strict and viceversa still modifies the signature, which is kind of annoying in my opinion. Compared to Haskell, where I can just add bangpatterns and sprinkle `!` in a few places, it's still less ergonomic.

I feel like there isn't really a good implementation of strict-by-default but lazy-on-demand functional programming that is ergonomic and gets out of the way, quite yet.

Re: An apologia of lazy evaluation

#52

Post by kazinator » Mon, Mar 27, 2023, 3:54 PM UTC

antonvs wrote: post #48

lispm wrote: post #33

Earlier quoted context omitted.

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…

Thanks for the correction and info. I have to retract my claim about the reason those languages use FEXPRs, but I'm not convinced they're good reasons. There are, however, very good reasons why the FEXPR approach has been abandoned by other languages, as the Pitman article points out. There are certainly better ways to achieve pretty much anything you might want FEXPR-style source code access for. Aside from the Lisp…

I'm thoroughly convinced that fexprs are a bad idea and so, good riddance. Our Lisp hacking predecessors did us a huge favor by figuring this out and documenting it.

Fexprs are hostile toward compiling. Specifically, True Scotsman's ahead-of-time compiling where we take an entire file or set of files and turn them into compiled equivalents, whereby we obtain:

1. Useful diagnostics without running the code.

2. Deliverables which load and execute faster, and don't require any code processing at run time (unless we choose that as part of application logic).

3. Resistance to reverse engineering, so we get paid. :)

Even a macro expander in front of an interpreter can provide error checking, such as finding unbound variables, reporting about misused special forms, and even things like functions being called with wrong numbers of arguments.

Macros themselves can be well written and provide decent error checking. So could fexprs, but fexprs have to be called.

You can't code walk fexprs because you don't know which parts of the argument material of a fexpr contains more fexprs.

It is counterproductive to lose the ability to completely code-walk a program, just to gain the ability to perpetrate trompe d'oeil metaprogramming: the software engineering equivalent of having a hand reach out of the picture, holding a pencil which draws the picture frame.

Re: An apologia of lazy evaluation

#53

Post by tome » Mon, Mar 27, 2023, 4:06 PM UTC

In my opinion space leaks are a big deal in Haskell. I come across them fairly often and they cause big problems for the kind of software I write. Luckily they are also easy to avoid. I wrote an article about how to eliminate half of them:

http://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrepr...

(the other half are eliminated by disabling the full-laziness transformation).