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 [email protected] through sheer volume --that is another misconception. --Mike to Peter _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
