From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Blake Shaw Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH v3] docs/match: pattern matcher example makeover Date: Fri, 03 Feb 2023 17:05:11 +0700 Message-ID: <7zk00zkoqc.fsf@reproduciblemedia.com> References: <20230201130930.6624-1-blake@reproduciblemedia.com> <9725d8d9-faf2-3306-94ae-209086aa5a82@telenet.be> <20230202144720.306d1bb3@aicha> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7285"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , guile-devel@gnu.org To: David Pirotte Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Feb 03 11:59:47 2023 Return-path: Envelope-to: guile-devel@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 1pNtnF-0001dZ-6U for guile-devel@m.gmane-mx.org; Fri, 03 Feb 2023 11:59:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNtm9-0002zL-Lw; Fri, 03 Feb 2023 05:58:37 -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 1pNtm7-0002yF-Bx for guile-devel@gnu.org; Fri, 03 Feb 2023 05:58:35 -0500 Original-Received: from out-148.mta1.migadu.com ([95.215.58.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNtm1-0005ni-DQ for guile-devel@gnu.org; Fri, 03 Feb 2023 05:58:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reproduciblemedia.com; s=key1; t=1675421411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HRV2omPhwAxOTcVuRC7gneWfUMDf2C0CNURre9l0X9M=; b=Pec/MuPDPav0Q1xTLfeP8Ub8pfgYE9i5SXKhvg2lpDlaGIeoObVm+ToSAQgmeJ3H50InmE 9/m+17ix/SaV5Q0KsqfSNNmEL/0DU7KqhWoTeTmLD+2lHpqrU7Kf0ju6PcQF9tGskywFYg tMzvXRv+EY1PvSWkGwyw00d62tdnpRw= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: <20230202144720.306d1bb3@aicha> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=95.215.58.148; envelope-from=blake@reproduciblemedia.com; helo=out-148.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21674 Archived-At: David Pirotte writes: > Not at all - and quite annoying. imo. > So i'd 'vote' not to use them anywhere in the guile reference manual take the following functions in both styles: (let unwrap ((peel '(((((unnest arbitrary nestings))))))) (match-let* (((core ...)) peel) ((wrapper ...) core)) (if (> (length wrapper) 1) wrapper (unwrap wrapper)))) (let () (define-record-type person (make-person name friends) person? (name person-name) (friends person-friends)) (letrec ((alice (make-person "Alice" (delay (list bob)))) (bob (make-person "Bob" (delay (list alice))))) (match alice (($ person name (= force (($ person "Bob")))) (list 'friend-of-bob name))))) (let unwrap ([peel '(((((unnest arbitrary nestings)))))]) (match-let* ([([core ...]) peel] [(wrapper ...) core]) (if (> (length wrapper) 1) wrapper (unwrap wrapper)))) (let () (define-record-type person (make-person name friends) person? (name person-name) (friends person-friends)) (letrec ([alice (make-person "Alice" (delay (list bob)))] [bob (make-person "Bob" (delay (list alice)))] (match alice [($ person name (= force (($ person "Bob")))) (list 'friend-of-bob name)]))) Without copy and pasting, which have errors, and where? My wager is that unless you are already quite well adjusted to lisp, its much easier to catch the errors in the "Indiana" style examples, and if you are quite well adjusted to lisp, you aren't really impacted by these conventions in documentation in any concrete, meaninglful way. > It makes the code appear as if it was another language, and requires > you train yourself to ignore them - as they actually do _not_ have any > specific meaning, but nonetheless 'pretend they do', by their mere > presence, and this causes a reading nuisance. Well, these conventions can be found throughout the gamut of scheme literature going back to the 80s, and some of the largest scheme projects, such as Chez, Racket, etc. employ them. So if you're getting into Scheme, you'll necessarily encounter them, and if you haven't been made aware that brackets are syntactic sugar for parens in Scheme, or if that doesn't become apparent with some quick repl experimentation, you've probably jumped into pattern matching a bit too quickly. But overall, it seems the objections against the Indiana style here are primarily concerned with individual, current user/contributor preferences, rather than out of a concern for the target audience, which are newcomers.