Re: String representation

2000-12-21 Thread Nicholas Clark
On Thu, Dec 21, 2000 at 05:36:05PM +, Nick Ing-Simmons wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > >> > >> where it is possible to get "smart" when one arg is a "special case" of > >> the other. > > > >> And similarly numbers must be convertable to "complex long double" or > >> wha

Re: String representation

2000-12-21 Thread Nick Ing-Simmons
Nicholas Clark <[EMAIL PROTECTED]> writes: >> >> where it is possible to get "smart" when one arg is a "special case" of >> the other. > >> And similarly numbers must be convertable to "complex long double" or >> what ever is the top if the built-in tree ? (NV I guess - complex is >> over-kill.)

Re: String representation

2000-12-21 Thread Nicholas Clark
On Wed, Dec 20, 2000 at 11:07:39PM +, Nick Ing-Simmons wrote: > The snag is that there are common pairs > e.g. concat(utf8,ascii) / concat(ascii,utf8) > or > plus(NV,IV) / plus(IV,NV) > > where it is possible to get "smart" when one arg is a "special case" of > the other. >

Re: mixed numeric and string SVs.

2000-12-21 Thread Nick Ing-Simmons
David Mitchell <[EMAIL PROTECTED]> writes: >> > 2. Each SV has 2 vtable pointers - one for it's numeric representation >> > (if any), and one for its string represenation (if any). Flexible, but >> > may require an extra 4/8 bytes per SV. >> >> It may not be terrible. How big is the average SV al

Re: String representation

2000-12-21 Thread Philip Newton
On 18 Dec 00, at 15:21, Nick Ing-Simmons wrote: > There needs to be a hierachy of _repertoires_ such that: > > ASCII is subset of Native is subset of wchar_t is subset of UNICODE. But we can't even rely on that. I can imagine a couple of Native encodings around that fiddle with ASCII (for exam

Re: String representation

2000-12-21 Thread Nick Ing-Simmons
Philip Newton <[EMAIL PROTECTED]> writes: >On 18 Dec 00, at 15:21, Nick Ing-Simmons wrote: > >> There needs to be a hierachy of _repertoires_ such that: >> >> ASCII is subset of Native is subset of wchar_t is subset of UNICODE. > >But we can't even rely on that. I can imagine a couple of Native