At 09:05 AM 8/15/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: >I don't see why. I don't think we should be dealing with *multiple*
>internal
>: >encodings. That would be Bad and Wrong.
>:
>: Why not? We're going to have two already, binary and UTF-something, and if
>: we provide an option for UTF-8, -16, and -32 we're going to need the code
>: *anyway*, so what's wrong with having them all available?
>
>A small perl will force everything to one form, and a large perl will
>have code to handle all permutations lazily.
Hmmm. Maybe a two-level approach to the vtable's in order. First pointer
points to a table indexed by the type of the second operator, with entry 0
being the fallback for unknown types or something. The question there is
whether the simpler routines offset the expense of the double indirection.
>But in any case, the
>abstract model as viewed from the Perl language will make this
>transparent. Violating that abstract model would be Bad and Wrong.
Yup, works for me. Is a statement like "All X comparisons treated as the
platform-native X" OK (for X in string, integer, float) in the 'small perl'
model? (Assuming then that there's no core knowledge of BigInts, BigRats,
or Complex numbers in small perl)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
