Peter Bex scripsit:

> I'm a little confused on how this works.  There seems to be a discussion
> list specifically for WG2, but I got an error message stating I wasn't
> subscribed.  How does one subscribe to it?  The webpages at
> scheme-reports.org don't mention it, and the archives aren't mailman,
> like this list is.

It's a Google Group, so you can sign up at
<https://groups.google.com/group/scheme-reports-wg2>.

> As I understand WG2, it'll be a truly huge effort, containing many
> separate libraries, which any particular implementation doesn't need to
> support in its entirety: it can pick and choose which libraries to
> support.

Basically correct, and the bulk of our voting will be about specific
SRFIs (where R6RS chapters count as SRFIs).  There will be a certain
number of ballots like this one, about where it makes sense to promote
a MAY or a SHOULD to a MUST in order to support application development.
There will, for example, be a ballot about making IEEE support a MUST.

> I agree, this situation sucks and I'm hoping to eventually fix this by
> integrating bignum support in core.  However, note that this is different
> from what I'm suggesting: I'm not saying the complete numeric tower
> should be an optional add-on, but that it should only be required by
> specific parts of WG2.  See it as an additional constraint on some
> parts of WG2, which only apply *when you want to support those parts*.

Understood.  It's perfectly fine to vote no, in that case.

> The same is true for low-level macros, for example.  If WG2 decides to
> standardise, say, explicit renaming macros, another library might require
> them.  If an implementation doesn't support that library, it doesn't need
> to support explicit renaming macros either.

Sure, with the caveat that outside the limited realm of macros, it's
interface rather than implementation that counts for WG2 purposes.
The sample implementation of sets uses hash tables internally, but you
can implement sets without implementing hash tables, because there is
nothing in the set API that refers to them.

However, the set API as well as the new hash-table API to replace SRFI
69 (still in progress) depends on comparators, and therefore I intend to
propose comparators as a mandatory part of R7RS-large, so that people can
just assume (as they can with the existing R7RS-small types) that they
are available.  Being able to do this is part of the point of having a
-large *standard* as opposed to just writing a lot of SRFIs.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
An observable characteristic is not necessarily a functional requirement.
        --John Hudson

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.