R7RS-small bug report from comp.lang.scheme

[Arthur A. Gleckler]

I just ran across this in <comp.lang.scheme>:

<https://groups.google.com/forum/#!topic/comp.lang.scheme/YJA8UJvZznA>

Marc Nieper-Wißkirchen

R7RS provides the 'cond-expand' form in '(scheme base)'
and gives a definition for it on page 72 as a syntax-rules
macro. The definition uses the literal identifier
'library', which, however, is not being bound by the
'(scheme base)' library. Thus, a feature requirement as
'(library <library-name>)' can only be matched as long as
'library' remains unbound.

This is in contrast to the other auxiliary syntax in R7RS,
like 'else' and 'syntax-rules', which are required to be
bound in '(scheme base)'.

Therefore, I guess that the omission of 'library' in the
exports of '(scheme base)' in Appendix A was not on
purpose and that this should be amended in the
(unofficial) errata.

(Speaking of the list of errata: are there any efforts to
incorporate the errata in the R7RS TeX-file, thus creating
an R7.1RS until a new R8RS is agreed upon?)

Marc

I haven't replied yet because I wanted to check with you
guys first. I'd like to respond on his specific comments
(about `library' and about updating the TeX file), but also
to make a recommendation about where people should write
since the public discussion list still appears to be broken.

[Aaron W. Hsu]

Wasn't the library form initially supposed to be sort of "out of scope"
of the syntax elements? Thus, I wouldn't expect library to be bound as
an auxiliary syntax, though I guess I'd have to refresh myself
significantly on all of this. I guess if the library auxiliary syntax
were added, then one would need to make sure that it somehow doesn't
mess with the multiple uses of the term "library" throughout the text? I
do recall that the library form outside of cond-expand is not required
to be a syntax element in R7RS Small.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

[Alex Shinn]

On Wed, Feb 10, 2016 at 12:03 PM, Aaron W. Hsu <arc...@sacrideo.us> wrote:

>
>   R7RS provides the 'cond-expand' form in '(scheme base)'
>   and gives a definition for it on page 72 as a syntax-rules
>   macro.  The definition uses the literal identifier
>   'library', which, however, is not being bound by the
>   '(scheme base)' library.  Thus, a feature requirement as
>   '(library <library-name>)' can only be matched as long as
>   'library' remains unbound.
>
>   This is in contrast to the other auxiliary syntax in R7RS,
>   like 'else' and 'syntax-rules', which are required to be
>   bound in '(scheme base)'.

Wasn't the library form initially supposed to be sort of "out of scope"
of the syntax elements? Thus, I wouldn't expect library to be bound as
an auxiliary syntax, though I guess I'd have to refresh myself
significantly on all of this. I guess if the library auxiliary syntax
were added, then one would need to make sure that it somehow doesn't
mess with the multiple uses of the term "library" throughout the text? I
do recall that the library form outside of cond-expand is not required
to be a syntax element in R7RS Small.

The define-library form is definitely outside the realm of syntax.

Consistency with this would dictate that the keyword match

unhygienically, something we don't do anywhere else in R7RS

small, but which is best represented by leaving unbound (as

we did).

Consistency with other keywords would dictate we make this

auxiliary syntax.

In other words, it's debatable, and so I don't think appropriate

for an errata.

-- 

Alex

[John Cowan]

Alex Shinn scripsit:

> The define-library form is definitely outside the realm of syntax.

Yes. But this isn't about define-library forms. It's about the
use of the keyword `library` in cond-expand macros within ordinary
code, like this:

(define (imaginary x)
(cond-expand
((library (scheme complex)) (make-rectangular x -1))
(else (make-fake-imaginary x))))

Personally, I think embedding cond-expand into Scheme code like this
is very ugly (like random #ifdef in C), but R7RS-small does support it.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
La mayyitan ma qadirun yatabaqqa sarmadi
Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi.
--Abdullah al-Hazred, Al-`Azif

[John Cowan]

Arthur A. Gleckler scripsit:

> (Speaking of the list of errata: are there any efforts to
> incorporate the errata in the R7RS TeX-file, thus creating
> an R7.1RS until a new R8RS is agreed upon?)

I talked to Will about this, and we don't have the authority to do so,
only the SC can, and I doubt if they will.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

Big as a house, much bigger than a house, it looked to [Sam], a grey-clad
moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes,
but the Mumak of Harad was indeed a beast of vast bulk, and the like of him
does not walk now in Middle-earth; his kin that live still in latter days are
but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit"

[Arthur A. Gleckler]

Any news about the proper mailing list to use?

[John Cowan]

Arthur A. Gleckler scripsit:

> Any news about the proper mailing list to use?

No idea. Supposedly there exist proper backups of the scheme-reports
mailing list somewhere, but nobody knows where. Polling the SC
is probably the Right Thing at this point.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

Not to perambulate the corridors during the hours of repose
in the boots of ascension. --Sign in Austrian ski-resort hotel

[Alex Shinn]

On Wed, Feb 10, 2016 at 11:37 PM, John Cowan <co...@mercury.ccil.org> wrote:

Alex Shinn scripsit:

> The define-library form is definitely outside the realm of syntax.

Yes.  But this isn't about define-library forms.  It's about the
use of the keyword `library` in cond-expand macros

I know.  I was arguing for internal consistency between the

syntax and library declaration cond-expands.

Similarly at the start of a program we allow import, but the

keywords `only', `except', etc. are not auxiliary syntax (and

could not be).

-- 

Alex

[Alex Shinn]

Another point - the features themselves are not hygienic.

Do we view `library' as a special type of feature or as an

extension to the `cond-expand' syntax?

-- 

Alex

[Aaron W. Hsu]

On 02/10/2016 09:37 AM, John Cowan wrote:
> Alex Shinn scripsit:
>
>> The define-library form is definitely outside the realm of syntax.
>
> Yes. But this isn't about define-library forms. It's about the
> use of the keyword `library` in cond-expand macros within ordinary
> code, like this:
>
> (define (imaginary x)
> (cond-expand
> ((library (scheme complex)) (make-rectangular x -1))
> (else (make-fake-imaginary x))))
>
> Personally, I think embedding cond-expand into Scheme code like this
> is very ugly (like random #ifdef in C), but R7RS-small does support it.

I had forgotten that the library term in cond-expand and the
define-library term were different. Provided that we are not overloading
`library` for anything else in the language, I think it makes reasonable
sense to make `library` an aux keyword. One could still debate it, and
it still bothers me that there's a disconnect between all of this, but
that's the way R7RS was put together. I'm still not sure if it quite
reaches the point of an error, though I'd be fine if it were considered
an errata.

[Arthur A. Gleckler]

Marc, who started this thread originally on
<comp.lang.scheme>, asked me to post his reply to
<scheme-reports-wg1>:

From: Marc Nieper-Wißkirchen <marc....@gmail.com>
Subject: Re: [R7RS] Missing 'library' export in the base library?
Newsgroups: comp.lang.scheme
Date: Thu, 11 Feb 2016 02:56:22 -0800 (PST) (13 hours, 48 minutes ago)

Arthur,

thanks for forwarding my feedback to WG1 and including the link to the discussion on the other mailing list.

Reading the latest comments from Alex Shinn, it seems to me that the
semantics of cond-expand are not at all clear and that, if we take the
reference implementation on p.72 as a definition, it does not do what
it is supposed to do:

For example: Say, if only '(scheme base)' is being imported, 'read' is
not being bound. Thus the provided 'cond-expand' keyword will be able
to match '(library (scheme read))' only if 'read' is unbound in the
usage environment of the 'cond-expand' use.

Thus the clause '(library (scheme read))' would not work as soon as
'read' is being bound, for example by an earlier '(import (scheme
read))', which would not be an unlikely pattern in such a situation.

Apparently, a sensible 'cond-expand' cannot be written as a
'syntax-rules' macro as 'syntax-rules' macros do not compare symbols
but identifiers.

I would therefore propose to include at least the intended semantics
of 'cond-expand' in the list of errata (and to have it corrected in
R8RS at the latest); in particular, it should say something about
whether 'library' should be matched as a symbol, hygienically as an
unbound identifier or hygienically as a bound identifier. If the 'and'
and 'or' clauses are matched differently, this might lead to
confusion.

As I cannot post the WG1 mailing list, would you mind forwarding the above to that list?

Best,

Marc