Re: REPL and load deifferences (was Re: Proposal for a new (ice-9 history))

[Göran Weinholt]

Mikael Djurfeldt <address@hidden> writes:

> And, the attachments...
>
> On Tue, Oct 30, 2018 at 11:21 AM Mikael Djurfeldt <address@hidden> wrote:
>
>  On Tue, Oct 30, 2018 at 1:55 AM Mikael Djurfeldt <address@hidden> wrote:
>
>  On Tue, Oct 30, 2018 at 12:55 AM Mark H Weaver <address@hidden> wrote: 
>
>> More precisely, it is a literal
>> identifier recognized by 'match' and related macros, in the same sense
>> that 'else' and '=>' are literal identifiers recognized by the 'cond'
>> macro.

>> R5RS section 4.3.2 (Pattern language) specifies how these literal
>> identifiers are to be compared with identifiers found in each macro use:

>> Identifiers that appear in <literals> are interpreted as literal
>> identifiers to be matched against corresponding subforms of the
>> input. A subform in the input matches a literal identifier if and
>> only if it is an identifier and either both its occurrence in the
>> macro expression and its occurrence in the macro definition have
>> the same lexical binding, or the two identifiers are equal and both
>> have no lexical binding.

Guile's documentation says something else: "A literal matches an input
expression if the input expression is an identifier with the same name
as the literal, and both are unbound(1)." What happened to the case
where they have the same binding?

> [...]
> Incidentally, this does *not* throw an error in master (unless I made
> some mistake in this late hour), which then is a bug!

There is a catch for R6RS users of Guile with the standard literals
'else', '=>', etc. They are not bound in Guile's standard library, so if
a library exports 'else' then the built-in 'cond' no longer recognizes
'else' for users of that library.

This is not how other R6RS implementations behave, but IIRC it is
somehow expected that Guile behaves this way. It leads to annoying and
hard to find bugs.

-- 
Göran Weinholt
Debian developer
73 de SA6CJK