I'm surprised that we don't make the old functionality controlled by a variable of some sort.
i.e. $UNICODE_ENABLED = 0; shortcut: $:-( = 0; where the default is 1. much like: $/ (hmm, I like the multibyte smilely convention, that would be interesting) of course it will require a visit to existing functionality but it does help the forward migration. btw: I do agree that there are times when a single byte output is required. for example when parsing/building legacy data files. = > -----Original Message----- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 12:39 PM > To: [EMAIL PROTECTED] > Subject: Re: BOM and principle of least surprise > > > On Wed, May 05, 2004 at 07:47:53PM +0300, Jarkko Hietaniemi wrote: > : We tried this with perl 5.8.0 and the feedback was overwhelmingly > : negative... if people do "print chr 0xff" they do expect one byte, > : not two. > > We'll just have to figure out how to retrain those people for > Perl 6. The binary/text distinction is important enough on > filehandles that I'm tempted to resort to different keywords > to open them, just to force people to be specific. 'Course, > that doesn't help with stdout... > > A non-serious suggestion is that we pull the same trick and > force people to specify by name whether they're running a > version of Perl that defaults to text or binary, so they have > to invoke #!/usr/bin/tperl or #!/usr/bin/bperl. But > realistically, Perl is going to continue to default to text > mode, which means we have to make it simple to switch to > "binary-filter mode" on stdin and stdout. (Presumably stderr > remains textish.) > > Right now, the meaning of "text" is subject to severe > distortions due to legacy issues. But in the long run, > "text" is going to mean Unicode, and that probably means a > UTF-8 file encoding at least in the western world, and > probably something else in the eastern world (but in either > case, the file encoding is hidden behind the filehandle as > far as Perl is concerned). The P5-to-P6 transition is a > reasonable time to bite that bullet. Not sure how much fence > straddling Ponie can do though... > > It would be really nice if the OS guys would get their > collective act together and provide APIs to tell programs > what their expectations are, but the next few years are > likely to remain chaotic in that respect, and we're likely to > see many "bandaids" in the form of environment variables, > which are the wrong solution to most API problems. But we > have to aim Perl 6 for the time when things will eventually > settle down. That doesn't mean that we have to make Unicode > the default right away if we decide it's impossible to "bite > the bullet" right now--but it does mean at miminum that there > shouldn't be any default other than Unicode, and if we force > people to be explicit right now, there has to be a way of > simplify the API later when it's reasonable to default to > Unicode. That's probably the transitional form that Perl 5 > and Ponie have to go through anyway, even if Perl 6 manages > to force the issue. > > Larry > >
