Re: [Chicken-hackers] Re: [Chicken-users] Bignums in core

[John Cowan]

Kon Lovett scripsit:

> Personally I want a core Chicken with a component orientation towards  
> the major sub-systems. I mean "pluggable & composable" string, number,  
> gc, concurrency, file components; not to be construed as an exhaustive  
> list.

I agree.  My complaint with Chicken in its current state is that it's
not composable *enough*.

For example, an application may use the numbers egg, but contain compiled
parts that don't use it.  As long as the app uses only fixnums, all is
well; but the minute it computes an exact integer that (all unknown) is
too big to be a fixnum, parts of the application won't even *recognize*
the value as numeric any more, never mind being able to do arithmetic with
it.  That requires the program to either be written with extra-special
care, keeping the representation types in mind all the time (not very
Schemey), or else all the components have to be recompiled from scratch,
including the core, in order to get a consistent view.

Per contra, strings are the same type everywhere, but what is their
meaning?  In parts of your code compiled with the utf8 egg, the range
of characters a string can hold is the full #\x0 to #\x10FFFF; in
other parts, the range is just #\x0 to #\xFF, and the representations
aren't compatible except in the ASCII range, so each part has to be very
careful not to corrupt the strings created and used by the other part --
they don't really interoperate, they just *appear* to interoperate,
and this time you don't even get a type-mismatch warning.

Strings and numbers, these aren't random application data types that some
components know about and others treat opaquely.  These are part of the
core of the Scheme language.  I remember I got quite a shock when writing
the Q egg to discover that (use numbers) didn't affect the FFI in any way,
and I was still restricted to the same old fixnum-flonum interface to C
code.  Q and Chicken use the same representation for bignums, but the only
way to safely share across the interface was to have each side render the
bignum to a digit string (which the FFI can deal with, both sides being
safely UTF-8) and reparse it on the other side.  Terrible for efficiency.

> I see Chicken at an architectural cross-roads. Rather than pilling  
> capability into the core perhaps we should consider something that  
> qualifies as "it's all chickens down."

In the Real World, unlike Discworld, things have to ground out somewhere.
That's the C side.  What the C side understands is what Chicken
understands.

I really like Chicken.  I think it's a great Scheme.  And there are plenty
of programs for which ASCII-only strings and fixnum/flonum arithmetic
is sufficient.  When those limits *aren't* sufficient, though, Chicken
claims to be extensible to meet them, but really isn't.

-- 
That you can cover for the plentiful            John Cowan
and often gaping errors, misconstruals,         http://www.ccil.org/~cowan
and disinformation in your posts                address@hidden
through sheer volume --that is another
misconception.  --Mike to Peter