[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



(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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports