unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: lloda <lloda@sarc.name>
Cc: "guile-devel@gnu.org" <guile-devel@gnu.org>,
	"Linus Björnstam" <linus.bjornstam@veryfast.biz>,
	"Lassi Kortela" <lassi@lassi.io>
Subject: Re: Add internal definitions to derived forms
Date: Tue, 24 Jan 2023 10:02:38 +0100	[thread overview]
Message-ID: <87mt68wbip.fsf@gnu.org> (raw)
In-Reply-To: <588FD427-B3C2-4946-83E9-74978E2D3C62@sarc.name> (lloda@sarc.name's message of "Tue, 24 Jan 2023 00:28:10 +0100")

Hi!

lloda <lloda@sarc.name> skribis:

>>> @lisp
>>> -(@var{test} @var{body} @dots{})
>>> +(@var{test} @var{body})
>> 
>> 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.

[...]

> This was actually the main thing I wanted to fix in this patch. Linus' patch had ‘body ...’ but that clearly means ‘zero or more bodies’, which doesn't work because there's exactly one ‘body’. I.e. ‘body’ isn't an expression that is tagged ‘body’, it's, well, a ‘body’.

Yeah, ‘body’ is a bit confusing here; in the example above, I’d have
written:

  (@var{test} @var{exp} @dots{})

because that’s what the “body” is: one or more expressions.

> The Scheme reports use one ‘<body>’ and no dots in all these definitions. See also the definition of let in the linked section ‘Local Bindings’, which again uses ‘body’ and no dots. I hoped that section would count as definition of ‘body’, and the section on ‘Internal Definitions’ explains precisely what can go into ‘body’, so I linked to that as well. I see that isn't clear enough. Maybe ‘body’ should be explicitly defined in one of these sections?

Damn it, I hadn’t realized this was a widespread convention, but yeah,
R5RS and parts of the Guile manual follow this convention.  So hmm, the
change you propose makes a lot of sense to me now.

So yeah overall I guess we should always write one of:

  (something @var{body})

or:

  (something @var{exp} @dots{})

Using @var{body} like you do in this patch is consistent with other
parts of the manual, so it LGTM.

Thanks,
Ludo’.



  parent reply	other threads:[~2023-01-24  9:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 15:32 Add internal definitions to derived forms Linus Björnstam
2022-11-09 15:46 ` Damien Mattei
2022-11-17  7:25 ` lloda
2022-11-18  9:04   ` Linus Björnstam
2022-11-18  9:27     ` Lassi Kortela
2022-11-18  9:50       ` Linus Björnstam
2022-11-18 10:22         ` Lassi Kortela
2022-11-18 12:53           ` Linus Björnstam
2022-11-18 13:18             ` Lassi Kortela
2023-01-19 17:54             ` lloda
2023-01-20 17:37               ` lloda
2023-01-23 22:13                 ` Ludovic Courtès
2023-01-23 23:28                   ` lloda
2023-01-24  7:33                     ` Linus Björnstam
2023-01-24  9:02                     ` Ludovic Courtès [this message]
2023-01-24 17:59                       ` lloda
2023-01-25 10:33                         ` Ludovic Courtès
2023-01-25 15:09 ` Ludovic Courtès
2023-01-25 15:38   ` Greg Troxel
2023-01-25 21:38     ` Linus Björnstam
2023-01-25 21:06   ` Linus Björnstam
2023-02-02 11:17   ` lloda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mt68wbip.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    --cc=lassi@lassi.io \
    --cc=linus.bjornstam@veryfast.biz \
    --cc=lloda@sarc.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).