Re: [Scheme-reports] [scheme-reports-wg1] Arthur Gleckler's rationales for 4th ballo votes

I think the point to note here is that the BNF is titled as the "Formal Grammar" of Scheme. As such, including the specific constructs in there is arguably wrong, because these are not part of the grammar; rather, they are constructed on top of it.

For reference purposes, the syntax descriptions are sufficient IMO, especially since you rarely want to look up the syntax without also wanting to read up on the syntax parts' meanings, in which case the definitions in the BNF don't help you at all.

John's rationale says "There is now a disclaimer that the syntax keywords in 7.2 only "work" if they have not been redefined or shadowed. Keeping all the syntax in one place is handy enough that we should just leave them there." I was swayed by that argument. However, his vote is still "yes," which I interpret to mean that he is in favor of removing them.

John, is that what you mean?

John replied here that he thinks that the "scheme" namespace is already taken in some implementations. But going through the SchemeImplementors [1] list in the wiki, I cannot actually find one, with the exception of Chicken e (which doesn't use identifier lists for module names, so techically, "(scheme ...)" is still free).

So I am wondering: how did this perception materialize? Does SchemeImplementors miss major Scheme implementation with a "scheme" module namespace? Or did I just overlook something?

This shouldn't matter. Since we're probably going to use a different module form, e.g. `define-library', we're arguably in a different namespace anyway.

Having "define-record-type" in the default namespace doesn't mean that no other record system could exist next to it. On the other hand, putting it in a module could very well result in the unfortunate situation that one cannot portably define new data types because some implementations decide to omit support for "define-record-type" in favor of some other system. (Given the optionality of separate modules, such implementations would still conform to the standard.)

If some implementation includes a compatible superset of `define-record-type' that uses the same name, it would be useful to be able to distinguish it from the standard one by using a different module name. Putting the standard one in a module makes it easier to manage this.

Also, I would feel somewhat ridiculed if I had to explicitly import a module to define a simple record type. And sorry for the teachers that have to explain the reasoning for this to their students just to hear again how "unpractical" and "theoretical" Scheme is. ;)

I don't buy this argument. C programs typically don't do I/O without #include <stdio.h>, but that doesn't make C impractical or theoretical.

Actually, the explanation would be simple: the new split of Scheme into "two languages". This is the reason why I think that renaming would actually *reduce* confusion instead of generating it, because R7RS is really not a "revised R6RS" but something new.

Sure it's a revision of R6RS. It's just that the edits are major.

"r7rs-big" and "r7rs-small" are perfectly good names.