Peter Bex scripsit: > I haven't followed this discussion closely, so forgive me for being > completely unsure who is allowed to vote. On the off chance voting > is open to anyone, here's my vote: 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. > > 3) Should R7RS-large require support for exact complex numbers? > > No. The majority of Schemes don't even support this, AFAICT, so it's > not the report's place to suddenly start requiring it. The report > should attempt to standardise things available "in the wild", and only > where nothing useful exists yet should it *cautiously* invent new things. This is definitely not a new thing. I don't usually make numerical claims about what Schemes do (because Schemes, like legal witnesses, should be weighed rather than counted), and I don't feel competent to do so except in very general terms. Furthermore, I only have access to about half the Schemes on the "fairly complete list" at <http://community.schemewiki.org/?scheme-faq-standards#H-1rl08mk>. But since you already made a numerical assertion, there are 49 Schemes I've investigated on this point: 17 Schemes have both exact and inexact complex numbers, 8 have inexact complex numbers only, 1 has exact complex numbers only, 23 have no complex numbers. I've counted plain Chicken and Chicken+numbers separately for this purpose. 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. 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". 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. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org [R]eversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox --thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley -- 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.
