[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add internal definitions to derived forms

From: Ludovic Courtès
Subject: Re: Add internal definitions to derived forms
Date: Tue, 24 Jan 2023 10:02:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)


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

  (@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})


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]