(Answering on scheme-reports because I'm not a WG member.)

Am 30.08.2011 05:54, schrieb Arthur A. Gleckler:
> === #202 Semi-Editorial: Should we remove the specific syntaxes from
> the BNF in section 7? ===
>
> Even if they can be changed, it's good to have them enumerated for
> reference.

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.

> === #237 Change "scheme" in module names to "rsn" or "rs11" or
> something else ===
>
> "Scheme" is just the right term.  I certainly don't want scheme2011,
> which needlessly emphasizes the year.

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?

> === #240 Rename current-second to current-tai ===
>
> There's no reason that `current-second' is incompatible with returning
> fractional second values.  And we certainly don't want the redundant
> `current-tai-time'.

Seconded. "current-tai" would be particularly unfortunate as it requires
programmers to know what TAI is (which most programmers - including me
before following the WG - probably don't) to make the connection to time.

> === #269 module factoring (scheme record) ===
>
> Users may want to use more elaborate versions of `define-record-type'
> and make that clear through loading modules.

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.)

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. ;)

> === #231 WG1/WG2 Scheme naming proposal ===
>
> Changing the naming convention after all these years is bikeshedding
> and dropping a fun and respected tradition.  Furthermore, we'll have
> to explain the break over and over again.

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.

Another thing to consider for this decision is how to name the "big
language" report. I know that this is not what this vote is about, but
one should have this in mind because in the end, we need two names that
nicely fit together. I think that "R7RS" is problematic in this respect
because the "big language" report is not in its seventh revision - so
something with "R7" is not really appropiate - but on the other hand,
the name would have to reflect that it complements the "R7RS" report.
Versioning with the publishing year avoids this problem nicely.

Regards,
Denis

[1] http://trac.sacrideo.us/wg/wiki/SchemeImplementors