[r6rs-discuss] [Formal] (r6rs base) must also export _ and ... at level 1

From: Abdulaziz Ghuloum <aghuloum>
Date: Thu Jan 25 06:32:12 2007

On Jan 25, 2007, at 4:02 AM, Jed Davis wrote:

> On Wed, Jan 24, 2007 at 07:38:18AM -0500, AndrevanTonder wrote:
>> On Wed, 24 Jan 2007, Abdulaziz Ghuloum wrote:
>>> Andre van Tonder wrote:
>>>
>>>> It is stated on p.25 that (r6rs base) exports syntax-rules and
>>>> identifier-syntax at level 1. This is insufficient for writing
>>>> most
>>>> useful macros unless the identifiers ... and _ are also exported
>>>> for
>>>> level 1.
>>>
>>> Three questions:
>>> 1. Why would this be necessary?
>>
>> If they are not exported, how would you propose to handle renaming,
>> prefixing, or excepting them in a client library?
>
> After a few passes through the relevant bits of the spec, I think I
> finally understand what's going on with <literal>s, and there seem
> to be
> two issues here:
>
> 1) If ... and _ are not defined within (r6rs base), then things will
> work fine as long as those names aren't shadowed by the client code;
> they'll be free both at the point of use and in the definition, and
> thus
> will be equivalent up to free-identifier=? by dint of having the same
> name.

That's correct.

> However, if ... or _ is bound in the client library for whatever
> reason,
> then there's no way to get them back; there's no binding to rename, no
> value (at any phase) to re-bind, and no construct that ends the scope
> of a binding[*].

That's not fully correct.

If ... or _ is lexically bound, then the lexical binding prevails in
both
cases (it won't match if it's defined, and it won't match if it isn't).
Page 47 in r6rs-lib_92 lists some of these cases. So, you get the same
behavior if you shadow one of these literals by a lexical binding.
(If you used ... as a lexical, you better have a good reason.)

If some library exports ... or _ (for its own weird reason), then you
can
use rename/except/prefix to remedy the situation.

In either case, I don't see this necessary at all for writing any macro,
let alone *most* useful macros.

> 2) But, if the literals are bound in the scope where the macro is
> created, *then* they must be exported, or else the macro will be of
> limited use (which may be desired in some cases, but not this),
> because
> now the equivalence follows the actual bindings, not the text of the
> identifiers.
>
> As a convenient advantage, the literals may now be renamed and so on.

This is correct.

> 3) Bonus issue: the free-identifier=? behavior seems to suggest
> origins in the R5RS world, where the top-level scope is at the top of
> everything, and any free identifier might later become bound there.

I don't think that the potential of becoming bound at the top-level has
anything to do with how literals are matched in a macro definition.

> This strikes me as a little incongruous in R6RS, where the "scope" of
> such free identifiers is a sort of imaginary ultra-top-level
> outside of
> all libraries, which contains nothing and shall remain ever so.

I don't see the big deal with having two unbound identifiers with the
same name be free-identifier=?.

Aziz,,,
Received on Thu Jan 25 2007 - 06:31:37 UTC