From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.help Subject: Re: Lazy functional programming [was: Advantage using mapc over dolist] Date: Tue, 03 Dec 2024 22:17:33 +0100 Message-ID: <87bjxs4gb6.fsf@neko.mail-host-address-is-not-set> References: <87ed2qpo3o.fsf@gnu.org> <871pyqfl62.fsf@web.de> <87r06por3q.fsf@neko.mail-host-address-is-not-set> <8734j5lpbt.fsf@neko.mail-host-address-is-not-set> <87plm9s4cr.fsf@neko.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10159"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "help-gnu-emacs@gnu.org" To: Drew Adams , Heime , Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 03 22:18:12 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIaHZ-0002Ua-Uw for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 03 Dec 2024 22:18:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIaH8-0000eb-8g; Tue, 03 Dec 2024 16:17:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIaH6-0000eN-12 for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 16:17:40 -0500 Original-Received: from logand.com ([37.48.87.44]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIaH3-000432-V5 for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 16:17:39 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id C2BF51A0369; Tue, 3 Dec 2024 22:17:34 +0100 (CET) X-Mailer: emacs 29.4 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148576 Archived-At: On Tue 03 Dec 2024 at 20:08, Drew Adams 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!