Lazy functional programming [was: Advantage using mapc over dolist]

[Drew Adams <drew.adams@oracle.com>]

> From: Tomas Hlavaty
> Sent: Monday, December 2, 2024 9:50 PM
>
> lazy evaluation is what those LAMBDAs and
> FUNCALLs in my examples are about.

Yes, in effect you're _implementing_ lazy
evaluation here & there by using lambdas to
delay evaluation.  That's classic, but it's
not general lazy evaluation.  Explicit
do-something-lazy-here is different from
inherent laziness.

Similarly, lazy `cons' (Friedman & Wise)
isn't general lazy evaluation.  That provides
only lazy lists.

> purely functional languages are not about
> implicit lazy-evaluation, see purescript

It's really a matter of opinion - there's no
single, formal "purely functional" definition.
Meanings usually include characteristics such
as "side-effect free" and "referentially
transparent", but there can be more.

Applicative-order (strict/eager) evaluation
isn't, and normal-order (lazy) evaluation is,
guaranteed to terminate and return a correct
result - a big  difference when it comes to 
programming with functions.

Some evaluation strategies converge and others
may not.  Using "purely functional" only for
those that do makes sense to me.  This includes
normal-order (leftmost-outermost) evaluation,
and it includes optimal call-by-need rewrite 
strategies (only necessary reductions).
___

I recommend John Hughes's classic 1984 paper
"Why Functional Programming Matters".  See here
an excerpt from it that points to laziness and
higher-order functions as the "glue" that holds
functional programs together, as well as John's
own description of the paper.

https://www.emacswiki.org/emacs/DrewAdams#WhyFunctionalProgrammingMatters

By "glue" he's talking about modularity:

 "The ways in which one can divide up the
  original problem depend directly on the ways
  in which one can glue solutions together."

It's about the modularity advantages provided
by higher-order functions and lazy evaluation.

That they play this role of glue for functional 
programming is germane to the question about
heavy use of `mapc' and the like in Lisp.

(That doesn't mean that smart compilation and
some fiddling might sometimes work around the
lack of real support for them in Lisp.)

The paper itself is here:

https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

See also this page:

https://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm