[Top][All Lists]

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

Re: [Chicken-announce] [Chicken-users] [ANN] Numbers 3.0 released

From: John Cowan
Subject: Re: [Chicken-announce] [Chicken-users] [ANN] Numbers 3.0 released
Date: Sat, 4 Oct 2014 18:26:37 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

Peter Bex scripsit:

> I don't see how that helps.  What would (+ the-biggest-medinum 1) do?
> If it returns a flonum, we're back to where we are right now.

That's what I'm proposing for core.  And it does put us back where we
are now in terms of pure Scheme operations, though in a way that both
R5RS and R7RS explicitly permit.  By the way, there are a variety of
other fixnum-flonum-only Schemes, most of them embedded Schemes or small
interpreters, though Stalin has the same tower as Chicken.

But we are *not* back to where we are now in terms of FFI, because
every C number has a Chicken core representation of bounded length.
The fact that some C integers become inexact when copied to Scheme is,
I think, the main motivation for extending bignums to the core, given
that we aren't going to put *all* numbers into the core.

> If it overflows or clamps, that worse than what we have now.

Agreed.  That's simply not Scheme, though throwing an exception would
be -- there are in fact Schemes whose bignums can't fill all of memory,
and do signal when you try to make a too-big bignum (not that I would
recommend that).

> If it results in a bignum, you end up exactly in the situation I
> described, where any operation can return numbers unbounded in size.

That's what I propose for the numbers egg, but not for core.

> > This is also a requirement for transitivity.
> It sucks.

Non-transitive <, >, and = make for problematic reasoning.

John Cowan        address@hidden
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]