On Tue, Apr 29, 2014 at 08:53:35AM -0400, John Cowan wrote: > Thanks for voting. At this point, the act of voting puts you on WG2, > provided it seems obvious to me that you're qualified for membership in > the sense of knowing something about Scheme. Which you are. 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. > So it's true that across all Schemes, a majority don't support exact > complex numbers, or any complex numbers, but *of those which support > complex numbers*, a 2:1 majority support both exact and inexact. > Including, as it happens, Chicken+numbers. I stand corrected. Still, I believe WG2 should not require compnums to support exact components. > Now for the wider point: > > I agree with you about the constraints on the WG inventing things, > but R7RS-large will require things from conforming implementations > that R7RS-small doesn't. Not every implementation is expected to > be -large; but application programs should be able to expect certain > things to be available from a -large implementation. In other words, > such implementations are meant to be "batteries included". 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. If this is correct, there's no point in requiring the full numeric tower for *the whole standard*. It's enough to say, for instance, "if you want to implement the RSA library, you must support bignums". This means that a Scheme which implements *other* parts of WG2 can still declare it is WG2-compatible, even if it does not offer bignums. > Much of the time this can be done by just requiring the presence > of certain libraries. But it's not possible to portably extend the > numeric tower, and indeed no Scheme except Chicken provides an easy way > to replace it as a whole. The result is far from seamless: unless every > module of a program imports the tower, there will be modules that don't > even recognize bignums, ratnums, rectnums, and compnums as numbers *at > all*, never mind being able to determine their values. 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*. 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. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
