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

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 20:08, Drew Adams <drew.adams@oracle.com> wrote:
>>> That doesn't mean that out-of-the-box ("OOTB") Lisp is designed for
>>> stream-oriented programming.

What are you hinting at?
Optimizing away those FUNCALLs?
Or something else?

>> 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.

Do you not consider purescript, elm, idris2 "purely functional
languages"?

> 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.

That sounds suspicious.
Is the trick in the meaning of "guaranteed"?

> 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

Thanks for the links!