RE: BOM and principle of least surprise

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
> 
>