From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: lloda Newsgroups: gmane.lisp.guile.devel Subject: Re: Add internal definitions to derived forms Date: Tue, 24 Jan 2023 00:28:10 +0100 Message-ID: <588FD427-B3C2-4946-83E9-74978E2D3C62@sarc.name> References: <2f38c5ea-0cb6-494e-b680-70b39c3291fb@app.fastmail.com> <38A58B58-3E5C-48EA-A108-1255982789DF@sarc.name> <39109fe3-4f7f-8d07-51ba-f9f993ab5c0d@lassi.io> <8187541f-a4e0-2f26-e8b7-df7fb82bb9f0@lassi.io> <2ffeb6fa-87eb-4008-9881-91b3e71a1fc3@app.fastmail.com> <87h6wgzyqb.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1765"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "guile-devel@gnu.org" , =?utf-8?Q?Linus_Bj=C3=B6rnstam?= , Lassi Kortela To: =?utf-8?Q?Ludovic_Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 24 00:28:45 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 1pK6F3-0000H6-BX for guile-devel@m.gmane-mx.org; Tue, 24 Jan 2023 00:28:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pK6Ej-0003cn-6n; Mon, 23 Jan 2023 18:28:25 -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 1pK6Eh-0003cG-3Y for guile-devel@gnu.org; Mon, 23 Jan 2023 18:28:23 -0500 Original-Received: from mta-14-4.privateemail.com ([198.54.118.206]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pK6Ee-0004BA-EF; Mon, 23 Jan 2023 18:28:22 -0500 Original-Received: from mta-14.privateemail.com (localhost [127.0.0.1]) by mta-14.privateemail.com (Postfix) with ESMTP id DA77518000AA; Mon, 23 Jan 2023 18:28:16 -0500 (EST) Original-Received: from [192.168.1.105] (unknown [51.154.167.214]) by mta-14.privateemail.com (Postfix) with ESMTPA id B73D018000A2; Mon, 23 Jan 2023 18:28:12 -0500 (EST) In-Reply-To: <87h6wgzyqb.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Virus-Scanned: ClamAV using ClamSMTP Received-SPF: pass client-ip=198.54.118.206; envelope-from=lloda@sarc.name; helo=MTA-14-4.privateemail.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_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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:21621 Archived-At: Hi Ludovic, > On 23 Jan 2023, at 23:13, Ludovic Court=C3=A8s wrote: >=20 > Hi Daniel, >=20 > Chiming in late in the discussion=E2=80=A6 >=20 > lloda skribis: >=20 >> =46rom 7aea299373f7370f31c9701035260ad412763724 Mon Sep 17 00:00:00 = 2001 >> From: Daniel Llorens >> Date: Thu, 19 Jan 2023 16:23:29 +0100 >> Subject: [PATCH 2/2] Fix documentation for forms taking lambda-like = bodies >>=20 >> * doc/ref/api-control.texi (Conditionals): Use 'body' in the syntax >> description of when, unless, cond, case. >> * doc/ref/api-binding.texi (Local Bindings): Normalize description of >> body return values. >> (Multiple values): Normalize use of 'body' and description of body >> return values. >=20 > What about: > s/Fix documentation=E2=80=A6/doc: Document multiple-value returns in = let, cond, etc./ > ? >=20 > (That would clarify what=E2=80=99s being fixed.) Ok. >=20 >> +++ b/doc/ref/api-binding.texi >> @@ -128,6 +128,8 @@ expressions has a few properties which are well = worth knowing. >>=20 >> The most basic local binding construct is @code{let}. >>=20 >> +@cindex body >=20 > That=E2=80=99s not a great index entry because there=E2=80=99s no = context. Maybe: >=20 > @cindex body, of a @code{let} expression >=20 > ? Ok. I think the word is only used in this sense in the manual, but it = might too generic to be used alone. >> +with the special forms @code{when} and @code{unless}. As an added >> +bonus, these forms take a @ref{Local Bindings,lambda-like body}, = which can >> +contain @ref{Internal Definitions,internal definitions} and multiple = statements >> +to evaluate. >=20 > =E2=80=9CLambda-like body=E2=80=9D is not defined; I guess it=E2=80=99s = =E2=80=9Clambda-like=E2=80=9D in the > wrt. to local =E2=80=98define=E2=80=99, but it=E2=80=99s not = =E2=80=9Clambda-like=E2=80=9D for the more crucial > aspect of defining a procedure, so I=E2=80=99d avoid that phrase. = WDYT? Yes, I thought lambda-like was a tad distracting, so I went with 'body' = alone... > Also, @ref in the middle of sentences may render poorly in Info (info > "(texinfo) @ref"). I=E2=80=99d suggest =E2=80=9C(@pxref{Whatever})=E2=80= =9D at the end of the > sentence or proposition. Ok. >> Each @code{cond}-clause must look like this: >>=20 >> @lisp >> -(@var{test} @var{body} @dots{}) >> +(@var{test} @var{body}) >=20 > I think removing dots is incorrect here because it suggests, according > to the typographic conventions used in the document, that there can = only > be a single expression. >=20 >> @var{key} may be any expression, and the @var{clause}s must have the = form >>=20 >> @lisp >> -((@var{datum1} @dots{}) @var{body} @dots{}) >> +((@var{datum1} @dots{}) @var{body}) >=20 > Ditto. >=20 >> and the last @var{clause} may have the form >>=20 >> @lisp >> -(else @var{expr1} @var{body} @dots{}) >> +(else @var{body}) >=20 > Ditto. >=20 >> -@deffn {library syntax} receive formals expr body @dots{} >> +@deffn {library syntax} receive formals expr body >=20 > Likewise. This was actually the main thing I wanted to fix in this patch. Linus' = patch had =E2=80=98body ...=E2=80=99 but that clearly means =E2=80=98zero = or more bodies=E2=80=99, which doesn't work because there's exactly one = =E2=80=98body=E2=80=99. I.e. =E2=80=98body=E2=80=99 isn't an expression = that is tagged =E2=80=98body=E2=80=99, it's, well, a =E2=80=98body=E2=80=99= . The Scheme reports use one =E2=80=98=E2=80=99 and no dots in all = these definitions. See also the definition of let in the linked section = =E2=80=98Local Bindings=E2=80=99, which again uses =E2=80=98body=E2=80=99 = and no dots. I hoped that section would count as definition of = =E2=80=98body=E2=80=99, and the section on =E2=80=98Internal = Definitions=E2=80=99 explains precisely what can go into =E2=80=98body=E2=80= =99, so I linked to that as well. I see that isn't clear enough. Maybe = =E2=80=98body=E2=80=99 should be explicitly defined in one of these = sections? > Otherwise LGTM; it=E2=80=99s certainly an improvement to have = multiple-value > returns properly documented! >=20 > Thanks, > Ludo=E2=80=99.