[EMAIL PROTECTED] (Simon Cozens) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> iii) Never assume bytes.
Beware of breaking binary patching. That would be a very bad thing.
Silly example not entirely unlike code I've actually seen:
open B, "< /tmp/netscape.old";
$/ = undef;
$netscape = ;
cl
Dan Sugalski writes:
: 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)
Depends on what you mean by
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
Dan Sugalski writes:
: > iii) Never assume bytes.
:
: What, never? Not even in vectors and bitmaps? :)
:
: I agree, though. Character and byte are separate constructs and need to be
: dealt with separately.
Not sure what you guys mean. A string is a sequence of integers.
A sequence of inte
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 co
At 11:51 AM 8/15/00 +0900, Simon Cozens wrote:
>On Mon, Aug 14, 2000 at 10:44:33PM -0400, Dan Sugalski wrote:
> > > (I'm not really following Perl 6, but Unicode is obviously something
> > > I have a concern about. Please *do* CC me replies, just this once.)
>
> > > This is why we should:
> > >
On Mon, Aug 14, 2000 at 10:03:11PM -0500, Jarkko Hietaniemi wrote:
> > What did Jarkko mean by this:
> >
> > > (strict ANSI compiler was very unhappy with the vtables
> > > in the code)
> >
> > Does this mean that Perl Vtable is going to throw portability?
>
> Huh? That was the Storable ext
> What did Jarkko mean by this:
>
> > (strict ANSI compiler was very unhappy with the vtables
> > in the code)
>
> Does this mean that Perl Vtable is going to throw portability?
Huh? That was the Storable extension and how it declared its (static)
vtables, very little to do with perl6 code,
On Mon, Aug 14, 2000 at 10:44:33PM -0400, Dan Sugalski wrote:
> > (I'm not really following Perl 6, but Unicode is obviously something
> > I have a concern about. Please *do* CC me replies, just this once.)
> > This is why we should:
> > i) Make the choice of internal encoding (UTF-8/UTF-16
On Tue, 15 Aug 2000, Simon Cozens wrote:
> (I'm not really following Perl 6, but Unicode is obviously something
> I have a concern about. Please *do* CC me replies, just this once.)
>
> On Sat, Aug 05, 2000 at 11:16:46AM +, Nick Ing-Simmons wrote:
> > Agreed - but that is due to grafting it
(I'm not really following Perl 6, but Unicode is obviously something
I have a concern about. Please *do* CC me replies, just this once.)
On Sat, Aug 05, 2000 at 11:16:46AM +, Nick Ing-Simmons wrote:
> Agreed - but that is due to grafting it in late - and possibly
> trying to be too clever in
Bryan C . Warnock <[EMAIL PROTECTED]> writes:
>Perhaps string promotion a la SV promotion?
>
>You could have each string carry around an extra byte or two of
>overhead, and encode ASCII vs UTF8 (vs UTF32 vs FOO).
>
>Line disciplines would set the appropriate flag, and any string
>handling function
At 11:16 AM 8/5/00 +, Nick Ing-Simmons wrote:
>Benjamin Stuhl <[EMAIL PROTECTED]> writes:
> >It has also led to the perl5 internals being, to put it
> >bluntly, a horrible mess.
>
>Agreed - but that is due to grafting it in late - and possibly
>trying to be too clever intuiting whether existin
Perhaps string promotion a la SV promotion?
You could have each string carry around an extra byte or two of
overhead, and encode ASCII vs UTF8 (vs UTF32 vs FOO).
Line disciplines would set the appropriate flag, and any string
handling function could read the flag if it needed to differentiate
by
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>> No, that's the beauty of utf8: the C datatype is still
>> char* and as long
>> as you stick to 7-bits ASCII you won't know the
>> difference. wchar_t
>> comes from a totally different school of thought, where
>> all your strings
>> are instantly incomp
15 matches
Mail list logo
