Reformulated numeric-tower ballot
112 views
Skip to first unread message
John Cowan
Apr 28, 2014, 11:48:58 PM4/28/14
to scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
I'm reformulating the numeric tower ballot to eliminate talk of IEEE,
which is orthogonal to the questions being addressed. I don't think
this will affect anyone's vote except maybe Bill Schottstaedt's.
If it does change your vote, go ahead and revote. Those who haven't
voted and intend to, please vote! As before, the vote closes at noon
on 2014-05-06, Universal Time. (According to my calculations, Universal
Time is approximately 0.00002822495 light-smoots later than MIT Time.
That is, assuming I have not uglified where I should have derided or
vice versa.)
1) Should R7RS-large require arbitrarily large (up to implementation
restrictions like memory) exact integers?
2) Should R7RS-large require support for exact rational numbers?
3) Should R7RS-large require support for exact complex numbers?
4) Should R7RS-large require inexact complex numbers?
--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
Go, and never darken my towels again!
--Rufus T. Firefly
which is orthogonal to the questions being addressed. I don't think
this will affect anyone's vote except maybe Bill Schottstaedt's.
If it does change your vote, go ahead and revote. Those who haven't
voted and intend to, please vote! As before, the vote closes at noon
on 2014-05-06, Universal Time. (According to my calculations, Universal
Time is approximately 0.00002822495 light-smoots later than MIT Time.
That is, assuming I have not uglified where I should have derided or
vice versa.)
1) Should R7RS-large require arbitrarily large (up to implementation
restrictions like memory) exact integers?
2) Should R7RS-large require support for exact rational numbers?
3) Should R7RS-large require support for exact complex numbers?
4) Should R7RS-large require inexact complex numbers?
--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
Go, and never darken my towels again!
--Rufus T. Firefly
Alex Queiroz
Apr 29, 2014, 3:35:56 AM4/29/14
to John Cowan, scheme-reports, scheme-re...@googlegroups.com
Hello,
On Tue, Apr 29, 2014 at 5:48 AM, John Cowan <co...@mercury.ccil.org> wrote:
1) Should R7RS-large require arbitrarily large (up to implementation
restrictions like memory) exact integers?
Yes.
2) Should R7RS-large require support for exact rational numbers?
Yes.
3) Should R7RS-large require support for exact complex numbers?
Yes.
4) Should R7RS-large require inexact complex numbers?
Taylan Ulrich Bayirli/Kammer
Apr 29, 2014, 3:55:36 AM4/29/14
to Jay Freeman, John Cowan, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Jay Freeman <jay_reynol...@mac.com> writes:
> Thus I suggest that issue #1 not be addressed without also
> simultaneously addressing means whereby Scheme users who wish to trade
> accuracy for speed in numerical work, may do so.
I thought that was done simply by introducing an inexact number anywhere
in the calculation, since inexactness is "contagious". For example by
starting out with inexact constants ("1.0" instead of "1"), using the
`inexact' procedure on initial inputs, etc.
Taylan
> Thus I suggest that issue #1 not be addressed without also
> simultaneously addressing means whereby Scheme users who wish to trade
> accuracy for speed in numerical work, may do so.
I thought that was done simply by introducing an inexact number anywhere
in the calculation, since inexactness is "contagious". For example by
starting out with inexact constants ("1.0" instead of "1"), using the
`inexact' procedure on initial inputs, etc.
Taylan
John Cowan
Apr 29, 2014, 8:53:35 AM4/29/14
to scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
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.
[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
> 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?
>
> 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.
[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
John Cowan
Apr 29, 2014, 8:57:17 AM4/29/14
to Jay Freeman, scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Jay Freeman scripsit:
> And despite John Cowan's sneaky attempts at persuasion :-) , I have not
> joine scheme-reports-wg2; I am afraid someone might ask me to do some
> work. So this epistle will not appear there unless someone forwards it.
For the record: if I ask you to do something, it will be because you
seem to me to be the best person for the job, not merely because you
have joined the WG2 list. Lots of lurkers are on that list already,
and you are already not a lurker.
In any case, I have forwarded your ballot.
'My young friend, if you do not now, immediately and instantly, pull
as hard as ever you can, it is my opinion that your acquaintance in the
large-pattern leather ulster' (and by this he meant the Crocodile) 'will
jerk you into yonder limpid stream before you can say Jack Robinson.'
--the Bi-Coloured-Python-Rock-Snake
> And despite John Cowan's sneaky attempts at persuasion :-) , I have not
> joine scheme-reports-wg2; I am afraid someone might ask me to do some
> work. So this epistle will not appear there unless someone forwards it.
For the record: if I ask you to do something, it will be because you
seem to me to be the best person for the job, not merely because you
have joined the WG2 list. Lots of lurkers are on that list already,
and you are already not a lurker.
In any case, I have forwarded your ballot.
'My young friend, if you do not now, immediately and instantly, pull
as hard as ever you can, it is my opinion that your acquaintance in the
large-pattern leather ulster' (and by this he meant the Crocodile) 'will
jerk you into yonder limpid stream before you can say Jack Robinson.'
--the Bi-Coloured-Python-Rock-Snake
John Cowan
Apr 29, 2014, 9:34:59 AM4/29/14
to scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
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.
An observable characteristic is not necessarily a functional requirement.
--John Hudson
> 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.
An observable characteristic is not necessarily a functional requirement.
--John Hudson
Taylan Ulrich Bayirli/Kammer
Apr 29, 2014, 10:11:52 AM4/29/14
to John Cowan, scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Peter Bex <Pete...@xs4all.nl> writes:
> On Tue, Apr 29, 2014 at 09:34:59AM -0400, John Cowan wrote:
>> It's a Google Group, so you can sign up at
>> <https://groups.google.com/group/scheme-reports-wg2>.
>
> This just shows the archive. After enabling JavaScript, there's some
> more stuff but no sign-up instructions.
If I'm not mistaken, this seems to require a Google account. The "join
group" button appears when I sign in.
(FWIW, I don't find this nice, although I'm e-mailing from a Google
account right now.)
Taylan
> On Tue, Apr 29, 2014 at 09:34:59AM -0400, John Cowan wrote:
>> It's a Google Group, so you can sign up at
>> <https://groups.google.com/group/scheme-reports-wg2>.
>
> more stuff but no sign-up instructions.
If I'm not mistaken, this seems to require a Google account. The "join
group" button appears when I sign in.
(FWIW, I don't find this nice, although I'm e-mailing from a Google
account right now.)
Taylan
John Cowan
Apr 29, 2014, 10:36:47 AM4/29/14
to Taylan Ulrich Bayirli/Kammer, scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Taylan Ulrich Bayirli/Kammer scripsit:
> If I'm not mistaken, this seems to require a Google account. The "join
> group" button appears when I sign in.
You can also subscribe in the traditional way by sending an email to
scheme-reports...@googlegroups.com.
And they pack their lyrics till they're so damn dense
You could put 'em in your yard and you could use 'em for a fence.
--Alan Chapman, "Everybody Wants to Be Sondheim"
> If I'm not mistaken, this seems to require a Google account. The "join
> group" button appears when I sign in.
scheme-reports...@googlegroups.com.
And they pack their lyrics till they're so damn dense
You could put 'em in your yard and you could use 'em for a fence.
--Alan Chapman, "Everybody Wants to Be Sondheim"
Taylan Ulrich Bayirli/Kammer
Apr 29, 2014, 10:51:50 AM4/29/14
to John Cowan, scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
John Cowan <co...@mercury.ccil.org> writes:
> You can also subscribe in the traditional way by sending an email to
> scheme-reports...@googlegroups.com.
Thanks, good to know. FYI it's not documented in the help pages
> You can also subscribe in the traditional way by sending an email to
> scheme-reports...@googlegroups.com.
reachable through that JavaScript web interface; still, sorry for the
confusion.
Taylan
Taylan Ulrich Bayirli/Kammer
Apr 29, 2014, 12:14:04 PM4/29/14
to Jussi Piitulainen, John Cowan, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Jussi Piitulainen <jpii...@ling.helsinki.fi> writes:
> John Cowan writes:
>
>> [big snip] there are 49 Schemes I've investigated on this point: 17
> manipulated in ways that produce inexact results anyway - but then I
> realized/found out that they exist in number theory as "Gaussian
> integers" and "Gaussian rationals" and are of some interest as such.
I'm not sure if that's a convincing use-case. Inexact quaternions would
arguably be more useful due to their use in 3D graphics, and I don't see
them getting mandated in the numeric tower. It seems more reasonable to
put the limit on inexact complexes, if just due to existing adoption.
(FWIW I'm leaning towards voting no to all and asking them be optional
modules like everything else, as Peter Bex suggested.)
Taylan
> John Cowan writes:
>
>> [big snip] 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.
>
> I doubted the usefulness of exact complex numbers - wouldn't they be
>> 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.
>
> manipulated in ways that produce inexact results anyway - but then I
> realized/found out that they exist in number theory as "Gaussian
> integers" and "Gaussian rationals" and are of some interest as such.
I'm not sure if that's a convincing use-case. Inexact quaternions would
arguably be more useful due to their use in 3D graphics, and I don't see
them getting mandated in the numeric tower. It seems more reasonable to
put the limit on inexact complexes, if just due to existing adoption.
(FWIW I'm leaning towards voting no to all and asking them be optional
modules like everything else, as Peter Bex suggested.)
Taylan
John Cowan
Apr 29, 2014, 12:33:46 PM4/29/14
to Taylan Ulrich Bayirli/Kammer, Jussi Piitulainen, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Taylan Ulrich Bayirli/Kammer scripsit:
> (FWIW I'm leaning towards voting no to all and asking them be optional
> modules like everything else, as Peter Bex suggested.)
<chair hat="off">
The thing is, there's no way to do them as Scheme libraries or even
Scheme-compatible libraries, except to rebind the base numeric procedures
(as the Chicken egg does), which produces messy results. So I would urge
you not to do that.
</chair>
Today an interactive brochure website, tomorrow a global content
management system that leverages collective synergy to drive "outside of
the box" thinking and formulate key objectives into a win-win game plan
with a quality-driven approach that focuses on empowering key players
to drive-up their core competencies and increase expectations with an
all-around initiative to drive up the bottom-line. --Alex Papadimoulis
> (FWIW I'm leaning towards voting no to all and asking them be optional
> modules like everything else, as Peter Bex suggested.)
The thing is, there's no way to do them as Scheme libraries or even
Scheme-compatible libraries, except to rebind the base numeric procedures
(as the Chicken egg does), which produces messy results. So I would urge
you not to do that.
</chair>
Today an interactive brochure website, tomorrow a global content
management system that leverages collective synergy to drive "outside of
the box" thinking and formulate key objectives into a win-win game plan
with a quality-driven approach that focuses on empowering key players
to drive-up their core competencies and increase expectations with an
all-around initiative to drive up the bottom-line. --Alex Papadimoulis
Alex Shinn
Apr 30, 2014, 12:23:47 AM4/30/14
to scheme-re...@googlegroups.com, scheme-reports
On Tue, Apr 29, 2014 at 12:48 PM, John Cowan <co...@mercury.ccil.org> wrote:
I'm reformulating the numeric tower ballot to eliminate talk of IEEE,
which is orthogonal to the questions being addressed. I don't think
this will affect anyone's vote except maybe Bill Schottstaedt's.
4 has changed completely so I'm changing my vote.
1) Should R7RS-large require arbitrarily large (up to implementation
restrictions like memory) exact integers?
Yes (as required by R6RS).
[Caveat: I think it would be reasonable for an impl to fall
back to inexact representations for numbers that don't
fit exactly in memory, rather than throw an exception. This
may not be worth mentioning in the standard.]
2) Should R7RS-large require support for exact rational numbers?
Yes (as required by R6RS).
3) Should R7RS-large require support for exact complex numbers?
No (not required by R6RS, contrary impls exist).
4) Should R7RS-large require inexact complex numbers?
Yes. R6RS requires both complex numbers and inexact numbers.
Restricting inexact to reals would be inconsistent, and force e.g.
make-rectangular on inexact inputs to produce an exact result.
--
Alex
Taylan Ulrich Bayirli/Kammer
Apr 30, 2014, 3:44:46 AM4/30/14
to scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
John Cowan <co...@mercury.ccil.org> writes:
> 1) Should R7RS-large require arbitrarily large (up to implementation
> restrictions like memory) exact integers?
Yes. Mathematically correct behavior should be the norm, performance
> 1) Should R7RS-large require arbitrarily large (up to implementation
> restrictions like memory) exact integers?
issues the special-case.
> 2) Should R7RS-large require support for exact rational numbers?
> 3) Should R7RS-large require support for exact complex numbers?
previously, and there are significant implementations that don't support
it.
> 4) Should R7RS-large require inexact complex numbers?
One may ask why all these shouldn't be optional modules like everything
else, but problems pop up like 1) if a numeric type is supported, there
will probably be reader syntax for it as well, which generally can't be
enabled with an import (which will usually be processed after parsing),
2) overwriting bindings for +, -, etc. is strange, 3) I shouldn't need
an import or anything to get mathematically correct behavior in my
program, IMO it should be the norm.
It's unfortunate to marginalize embedded systems, but I'd rather see
them e.g. mentioned in an appendix as a special case instead of
complicating the main body of the standard.
Taylan
John Cowan
Apr 30, 2014, 12:04:04 PM4/30/14
to scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Peter Bex scripsit:
> If an implementation doesn't support hash tables, it might not need
> comparators either. This is the same objection as I have with requiring
> the full numeric tower.
Where do you draw the line? Lots of useful Scheme programs don't use
vectors for anything: do you advocate making them merely optional
as well? If not, why not?
> I don't see why this has to be. It will just exclude small
> specialised implementations which would still like to support
> a standardised library if it fits its intended use cases.
There's no reason *not* to exclude small specialized implementations
from a large standard. That doesn't mean the implementations
can't support libraries from -large if they want to: I assume
lots of libraries will work with Chibi even if they are not
packaged with it.
> For example, Chibi Scheme might decide to ship a few WG2 modules,
> but you can compile it without bignum support. Does that mean
> it isn't WG2-compatible?
If that ballot question passes, then yes, Chibi will not be R7RS-large
compliant when compiled without bignum support. Nothing wrong with that.
Is it not written, "That which is written, is written"?
> If an implementation doesn't support hash tables, it might not need
> comparators either. This is the same objection as I have with requiring
> the full numeric tower.
Where do you draw the line? Lots of useful Scheme programs don't use
vectors for anything: do you advocate making them merely optional
as well? If not, why not?
> I don't see why this has to be. It will just exclude small
> specialised implementations which would still like to support
> a standardised library if it fits its intended use cases.
There's no reason *not* to exclude small specialized implementations
from a large standard. That doesn't mean the implementations
can't support libraries from -large if they want to: I assume
lots of libraries will work with Chibi even if they are not
packaged with it.
> For example, Chibi Scheme might decide to ship a few WG2 modules,
> but you can compile it without bignum support. Does that mean
> it isn't WG2-compatible?
If that ballot question passes, then yes, Chibi will not be R7RS-large
compliant when compiled without bignum support. Nothing wrong with that.
Is it not written, "That which is written, is written"?
Alex Queiroz
Apr 30, 2014, 12:13:52 PM4/30/14
to John Cowan, scheme-reports, scheme-re...@googlegroups.com
Hallo,
On Tue, Apr 29, 2014 at 3:53 PM, Peter Bex <Pete...@xs4all.nl> wrote:
I don't see why this has to be. It will just exclude small
specialised implementations which would still like to support
a standardised library if it fits its intended use cases.
For example, Chibi Scheme might decide to ship a few WG2 modules,
but you can compile it without bignum support. Does that mean
it isn't WG2-compatible?
Is not this precisely the reason why R7RS was split in two? I do not see the point of small specialized implementations trying to conform to R7RS-large.
Cheers,
John Cowan
Apr 30, 2014, 1:01:37 PM4/30/14
to scheme-re...@googlegroups.com, scheme-reports
Alex Shinn scripsit:
> Yes. R6RS requires both complex numbers and inexact numbers.
Note, however, that it does not require numbers that are both
inexact and complex (in the sense of non-real).
> Restricting inexact to reals would be inconsistent, and force e.g.
> make-rectangular on inexact inputs to produce an exact result.
Or report an implementation restriction, or not exist at all
(it is in an optional library).
We want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures. --Samuel Gompers
> Yes. R6RS requires both complex numbers and inexact numbers.
inexact and complex (in the sense of non-real).
> Restricting inexact to reals would be inconsistent, and force e.g.
> make-rectangular on inexact inputs to produce an exact result.
(it is in an optional library).
We want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures. --Samuel Gompers
John Cowan
Apr 30, 2014, 1:32:30 PM4/30/14
to scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Taylan Ulrich Bayirli/Kammer scripsit:
> It's unfortunate to marginalize embedded systems, but I'd rather see
> them e.g. mentioned in an appendix as a special case instead of
> complicating the main body of the standard.
They are outside the charter remit in any case.
There is / One art / No more / No less
To do / All things / With art- / -Lessness --Piet Hein
> It's unfortunate to marginalize embedded systems, but I'd rather see
> them e.g. mentioned in an appendix as a special case instead of
> complicating the main body of the standard.
There is / One art / No more / No less
To do / All things / With art- / -Lessness --Piet Hein
Bakul Shah
Apr 30, 2014, 5:40:32 PM4/30/14
to Bear, John Cowan, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
On Wed, 30 Apr 2014 13:52:48 PDT Bear <be...@sonic.net> wrote:
> limits much higher than typical programming languages. It
> should not require an implementation to exhaust all memory
> and crash in an attempt to represent a very large exact integer.
I translate this to mean this: An implementation neeeds to
specify this limit in a symbolic constant in some form. It
should probably be a pair (x y) to indicate x^y (otherwise
just the "constant" will eat up all memory!).
> > 2) Should R7RS-large require support for exact rational numbers?
>
> It should require exact ratios. It should not require an
> implementation to exhaust all memory and crash in an attempt
> to represent a very precise ratio.
Ditto.
> > 3) Should R7RS-large require support for exact complex numbers?
>
> Previously I voted 'yes' subject to the same representation limits
> as other exact numbers. But as I consider this there's an issue.
>
> I would vote 'yes' for consistency with the rest of the numeric
> tower, but it is hard to say exactly what a 'yes' here means in
> the absence of any constraint on whether the exact numbers
> represented are, eg, stored in polar or cartesian format, or in
> some union that could be either, and if in polar format whether
> the angle measurement is given in radians (either directly or as
> some product of pi like degrees), or as a slope ratio.
I have difficulty imagining the usefulness of "exact" polar
representation. Seems to me, if you do allow exact complex
numbers, for polar<->cartesian conversion you would need
big-floats.
But must admit I am unclear about what "target audience or
market" R7RS-large is being designed for. I use it to solve
practical problems or for exploratory programming, in place of
perl/python/ruby/language-du-jour :-)
> On Mon, 2014-04-28 at 23:48 -0400, John Cowan wrote:
>
> > 1) Should R7RS-large require arbitrarily large (up to implementation
> > restrictions like memory) exact integers?
>
> It should require exact integers. It should encourage range
>
> > 1) Should R7RS-large require arbitrarily large (up to implementation
> > restrictions like memory) exact integers?
>
> limits much higher than typical programming languages. It
> should not require an implementation to exhaust all memory
> and crash in an attempt to represent a very large exact integer.
I translate this to mean this: An implementation neeeds to
specify this limit in a symbolic constant in some form. It
should probably be a pair (x y) to indicate x^y (otherwise
just the "constant" will eat up all memory!).
> > 2) Should R7RS-large require support for exact rational numbers?
>
> implementation to exhaust all memory and crash in an attempt
> to represent a very precise ratio.
Ditto.
> > 3) Should R7RS-large require support for exact complex numbers?
>
> as other exact numbers. But as I consider this there's an issue.
>
> I would vote 'yes' for consistency with the rest of the numeric
> tower, but it is hard to say exactly what a 'yes' here means in
> the absence of any constraint on whether the exact numbers
> represented are, eg, stored in polar or cartesian format, or in
> some union that could be either, and if in polar format whether
> the angle measurement is given in radians (either directly or as
> some product of pi like degrees), or as a slope ratio.
I have difficulty imagining the usefulness of "exact" polar
representation. Seems to me, if you do allow exact complex
numbers, for polar<->cartesian conversion you would need
big-floats.
But must admit I am unclear about what "target audience or
market" R7RS-large is being designed for. I use it to solve
practical problems or for exploratory programming, in place of
perl/python/ruby/language-du-jour :-)
John Cowan
Apr 30, 2014, 10:38:38 PM4/30/14
to Bakul Shah, Bear, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Bakul Shah scripsit:
> But must admit I am unclear about what "target audience or
> market" R7RS-large is being designed for. I use it to solve
> practical problems or for exploratory programming, in place of
> perl/python/ruby/language-du-jour :-)
Our charter describes the large language as:
a language that embodies the essential character of Scheme, that
is large enough to address the practical needs of mainstream
software development, and that can be extended and integrated
with other systems. [...] The language is not necessarily
intended for educational, research, or embedded use, though such
uses are not prohibited. Therefore, it may be a "heavyweight"
language compared to the language designed by working group 1.
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
> But must admit I am unclear about what "target audience or
> market" R7RS-large is being designed for. I use it to solve
> practical problems or for exploratory programming, in place of
> perl/python/ruby/language-du-jour :-)
a language that embodies the essential character of Scheme, that
is large enough to address the practical needs of mainstream
software development, and that can be extended and integrated
with other systems. [...] The language is not necessarily
intended for educational, research, or embedded use, though such
uses are not prohibited. Therefore, it may be a "heavyweight"
language compared to the language designed by working group 1.
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
Devon Schudy
May 1, 2014, 8:57:26 AM5/1/14
to John Cowan, scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
John Cowan wrote:
> Note also that fixnums often go up to 2^60 these days.
60-bit fixnums satisfy almost all of the practical need for bignums,
so they'd be a reasonable minimum. That would force 32-bit
implementations to provide bignums or at least fixed-precision boxed
integers (e.g. Java.lang.Long), but avoid unnecessary work for 64-bit
ones.
>> (This isn't a vote; I don't think I use Scheme enough to get a vote.
>> My opinion is relevant only because I'm one of the marginal practical
>> users R7RS-large is aimed at, who might use Scheme more if it were
>> less painful.)
>
> All the more reason for you to vote, because that voice needs to be
> represented on WG2. So please do.
All right, I vote no on all four. The full numeric tower is important
enough to standardize, but not important enough to require.
> Note also that fixnums often go up to 2^60 these days.
60-bit fixnums satisfy almost all of the practical need for bignums,
so they'd be a reasonable minimum. That would force 32-bit
implementations to provide bignums or at least fixed-precision boxed
integers (e.g. Java.lang.Long), but avoid unnecessary work for 64-bit
ones.
>> (This isn't a vote; I don't think I use Scheme enough to get a vote.
>> My opinion is relevant only because I'm one of the marginal practical
>> users R7RS-large is aimed at, who might use Scheme more if it were
>> less painful.)
>
> All the more reason for you to vote, because that voice needs to be
> represented on WG2. So please do.
All right, I vote no on all four. The full numeric tower is important
enough to standardize, but not important enough to require.
John Cowan
May 1, 2014, 10:33:56 AM5/1/14
to scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Peter Bex scripsit:
> Good question. I guess it's a little arbitrary. I would say the main
> difference is in the size of the standard. r5rs or r7rs-small is a
> reasonable size to implement in full, even for smallish implementations.
> Requiring the whole of r7rs-large to be implemented seems overkill.
Sure. Which is why I want to thoughtfully draw a line between the required
and the optional parts of the standard.
> Since it's going to be so very large, I'm unsure whether *any* Scheme
> (except, perhaps, for Racket)
Alas, the Racketeers are not even interested in R7RS-small; they consider
Racket to be a post-Scheme language.
> will implement every part of it.
I have hopes rather for the Scheme implementations that already have
large libraries and mostly just need to repackage them, like Chicken.
> [I]t's a good idea to avoid baking in too many assumptions about
> which subset of r7rs-large is going to be implemented in any compatible
> Scheme system.
A standard is a contract between implementer and user. Too few assumptions,
and the user suffers; too many assumptions, and the implementer suffers.
It's a Goldilocks problem: not too large, or too small, but just right.
> [I]f things like "needs built-in bignum support" are added to the spec,
> that may cause trouble.
In principle. But the only Schemes that are aimed at general application
development that lack bignums are Chicken and Wraith, and for Chicken
there is a straightforward workaround. (The chance that Stalin will
ever advance beyond R4RS is practically nil. The development community
around Stalin is about the most dysfunctional one I've ever encountered;
there isn't even a mailing list to send patches to.)
> And if it doesn't cause trouble, those parts of the spec that work with
> Chibi turn out to not really need bignum support. So why would you
> arbitrarily require it for the entire spec, even if many libraries
> aren't dependent on it?
So that application developers can count on just having bignums, like they
can count on having call/cc or tail recursion. Lots of implementations
of other languages do tail recursion to some degree, but the fact that
Scheme *requires* tail recursion allows a different programming style.
> But it would only not be compliant because it was declared not to be,
> for no real reason.
Equally true of any other standard feature.
Yes, chili in the eye is bad, but so is your ear. However, I would
suggest you wash your hands thoroughly before going to the toilet.
--gadicath
> Good question. I guess it's a little arbitrary. I would say the main
> difference is in the size of the standard. r5rs or r7rs-small is a
> reasonable size to implement in full, even for smallish implementations.
> Requiring the whole of r7rs-large to be implemented seems overkill.
Sure. Which is why I want to thoughtfully draw a line between the required
and the optional parts of the standard.
> Since it's going to be so very large, I'm unsure whether *any* Scheme
> (except, perhaps, for Racket)
Alas, the Racketeers are not even interested in R7RS-small; they consider
Racket to be a post-Scheme language.
> will implement every part of it.
I have hopes rather for the Scheme implementations that already have
large libraries and mostly just need to repackage them, like Chicken.
> [I]t's a good idea to avoid baking in too many assumptions about
> which subset of r7rs-large is going to be implemented in any compatible
> Scheme system.
A standard is a contract between implementer and user. Too few assumptions,
and the user suffers; too many assumptions, and the implementer suffers.
It's a Goldilocks problem: not too large, or too small, but just right.
> [I]f things like "needs built-in bignum support" are added to the spec,
> that may cause trouble.
In principle. But the only Schemes that are aimed at general application
development that lack bignums are Chicken and Wraith, and for Chicken
there is a straightforward workaround. (The chance that Stalin will
ever advance beyond R4RS is practically nil. The development community
around Stalin is about the most dysfunctional one I've ever encountered;
there isn't even a mailing list to send patches to.)
> And if it doesn't cause trouble, those parts of the spec that work with
> Chibi turn out to not really need bignum support. So why would you
> arbitrarily require it for the entire spec, even if many libraries
> aren't dependent on it?
So that application developers can count on just having bignums, like they
can count on having call/cc or tail recursion. Lots of implementations
of other languages do tail recursion to some degree, but the fact that
Scheme *requires* tail recursion allows a different programming style.
> But it would only not be compliant because it was declared not to be,
> for no real reason.
Equally true of any other standard feature.
Yes, chili in the eye is bad, but so is your ear. However, I would
suggest you wash your hands thoroughly before going to the toilet.
--gadicath
Jonáš Vidra
May 3, 2014, 4:37:47 PM5/3/14
to scheme-re...@googlegroups.com
On Tue, 29 Apr 2014 05:48:58 +0200 John Cowan wrote:
> 1) Should R7RS-large require arbitrarily large (up to implementation
> restrictions like memory) exact integers?
Yes.
> 1) Should R7RS-large require arbitrarily large (up to implementation
> restrictions like memory) exact integers?
> 2) Should R7RS-large require support for exact rational numbers?
> 3) Should R7RS-large require support for exact complex numbers?
> 4) Should R7RS-large require inexact complex numbers?
John Cowan
May 3, 2014, 6:02:04 PM5/3/14
to scheme-re...@googlegroups.com
Jonáš Vidra scripsit:
One Word to write them all / One Access to find them,
One Excel to count them all / And thus to Windows bind them.
--Mike Champion
> On Tue, 29 Apr 2014 05:48:58 +0200 John Cowan wrote:
>
> >1) Should R7RS-large require arbitrarily large (up to implementation
> >restrictions like memory) exact integers?
>
> Yes.
Thank you for voting.
>
> >1) Should R7RS-large require arbitrarily large (up to implementation
> >restrictions like memory) exact integers?
>
> Yes.
One Word to write them all / One Access to find them,
One Excel to count them all / And thus to Windows bind them.
--Mike Champion
John Cowan
May 7, 2014, 7:06:49 PM5/7/14
to Andy Wingo, scheme-...@scheme-reports.org, scheme-re...@googlegroups.com
Andy Wingo scripsit:
<flame>
> This discussion is frankly ridiculous. Where are Dybvig, Flatt, Clinger
> et al? Where is Feeley?
Where is Wingo?
> While I'm at it, where *is* the R7RS small final edition?
It is at <http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs.pdf>,
on the only site where WG members can post anything.
> Why is it not on R7RS.org?
Complain to Christian Stigen Larsen. If you want to know why it isn't
on scheme-reports.org, complain to the Steering Committee (viz. Clinger,
Feeley, Hanson, Rees, Shivers), and the best of luck to you -- I hope
you can get them to act.
> That this discussion of differences and requirements is happening *for
> the large version* is just... I don't know. I don't even know what to
> say. Good luck I guess but count me out.
So because you don't find your peers here, you're walking out instead of
helping? Talk about class snobbery! How about pitching in instead?
The implementer's viewpoint is greatly valued here -- when we can get it.
</flame>
<flame>
> This discussion is frankly ridiculous. Where are Dybvig, Flatt, Clinger
> et al? Where is Feeley?
Where is Wingo?
> While I'm at it, where *is* the R7RS small final edition?
It is at <http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs.pdf>,
on the only site where WG members can post anything.
> Why is it not on R7RS.org?
Complain to Christian Stigen Larsen. If you want to know why it isn't
on scheme-reports.org, complain to the Steering Committee (viz. Clinger,
Feeley, Hanson, Rees, Shivers), and the best of luck to you -- I hope
you can get them to act.
> That this discussion of differences and requirements is happening *for
> the large version* is just... I don't know. I don't even know what to
> say. Good luck I guess but count me out.
So because you don't find your peers here, you're walking out instead of
helping? Talk about class snobbery! How about pitching in instead?
The implementer's viewpoint is greatly valued here -- when we can get it.
</flame>
Christian Stigen Larsen
May 7, 2014, 8:10:53 PM5/7/14
to scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
John Cowan <co...@mercury.ccil.org>:
I registered r7rs.com for the sole purpose of not having to remember
the right location of r7rs-final (and, hopefully, to make it more googlable).
> If you want to know why it isn't on scheme-reports.org, complain to
> the Steering Committee (viz. Clinger, Feeley, Hanson, Rees, Shivers),
> and the best of luck to you -- I hope you can get them to act.
I emailed Jonathan Rees about this, and he forwarded it to Will (who does
the updates).
The site was actually updated some time ago. Scroll to the bottom, and
there is a link to r7rs-final + the errata. These are also on the wg1 subpage.
--
Christian Stigen Larsen
>> Why is it not on R7RS.org?
>
> Complain to Christian Stigen Larsen.
That's not mine, but registered by Olin Shivers.
>
> Complain to Christian Stigen Larsen.
I registered r7rs.com for the sole purpose of not having to remember
the right location of r7rs-final (and, hopefully, to make it more googlable).
> If you want to know why it isn't on scheme-reports.org, complain to
> the Steering Committee (viz. Clinger, Feeley, Hanson, Rees, Shivers),
> and the best of luck to you -- I hope you can get them to act.
the updates).
The site was actually updated some time ago. Scroll to the bottom, and
there is a link to r7rs-final + the errata. These are also on the wg1 subpage.
--
Christian Stigen Larsen
John Cowan
May 7, 2014, 8:49:36 PM5/7/14
to scheme-re...@googlegroups.com, scheme-...@scheme-reports.org
Christian Stigen Larsen scripsit:
> That's not mine, but registered by Olin Shivers.
>
> I registered r7rs.com for the sole purpose of not having to remember
> the right location of r7rs-final (and, hopefully, to make it more googlable).
Thanks. I had conflated r7rs.org and r7rs.com.
[P]olice in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows. When it's explained to them that they are in a different country,
where those rights do not exist, they become outraged. --Neal Stephenson
> That's not mine, but registered by Olin Shivers.
>
> I registered r7rs.com for the sole purpose of not having to remember
> the right location of r7rs-final (and, hopefully, to make it more googlable).
[P]olice in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows. When it's explained to them that they are in a different country,
where those rights do not exist, they become outraged. --Neal Stephenson
Arthur A. Gleckler
May 14, 2014, 4:56:52 PM5/14/14
to Andy Wingo, John Cowan, scheme-re...@googlegroups.com, scheme-reports
>> While I'm at it, where *is* the R7RS small final edition?
>
> It is at <http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs.pdf>,
> on the only site where WG members can post anything.
John I know this problem must be more frustrating to you than to anyone
else, but do fix it. Give Olin a call, his number is in the whois.
Through the efforts of John and of Jonathan Rees, it can now be found through a redirect from r7rs.org.
Reply all
Reply to author
Forward
0 new messages