[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
[MacPerl] RESEND: Meet the Newline, same as the old line (longish rant)
To: mac-perl
Subject: Meet the Newline, same as the old line (longish rant)
Date: Wed, 22 Oct 1997 17:08:51 +0200
From: Matthias Ulrich Neeracher <neeri>
As promised, here are a few thoughts about that eternal newline issue.
Perl scripts deal with a number of different classes of files:
1) Files KNOWN to be text: Everything that is parsed, whether it is the
main script or files included via use, require, or do.
2) Files KNOWN to be binary: Files on which the user has called binmode.
3) Files ASSUMED to be text: Files on which the <> operator is used and
$/ is set to "\n" or "".
4) Files about which nothing is known.
It is fairly uncontroversial that on category (1), every transformation would
be legitimate, and that on category (2), no transformation is legitimate.
Currently, UNIX perl and MacPerl do not perform any newline
transformations. DOSish perls transform all files in category 1, 3, and 4.
What initiated this thread was that I was asked to transform category 1
files. I have no philosophical objections to this, but it cannot be done well
in the current implementation: Program files are read internally via the <>
operator, which takes a fixed separator string, not a regexp. We could deal
with this by:
- Special casing the line reading routine for program files, which I won't do,
and which the Perl Porters probably wouldn't accept if I did.
- Extending $/ to accept regexps, which would be neat in its own right, but
probably not acceptable performance-wise to the Perl Porters for reading
program files.
- Probing a buffer full of input characters to find the correct newline
string, a solution which I suggested, but which was rejected by the Perl
Porters.
- Transforming the newline characters within the stdio library.
I *could* apply that last solution for category (1) files. It would slow down
parsing a bit, but probably not much. It would also do nothing for category 3
and 4 files, and the same people who are protesting about their script files
being non-portable would probably protest (with at least equally good
justification) about their data files being non-portable.
I *could* apply that solution to categories 1, 3, and 4, which would slow down
Perl a bit more. It would also break the current assumption that binmode is a
no-op in MacPerl, and thus the scripts of current users which so far have
worked perfectly well. It would, in fact, even break the scripts of the folks
who just wanted to run their UN*X perl script unmodfied, so it wouldn't even
get *them* off my back :-)
I *could* also apply that solution to categories 1 & 3, but that would break
entirely with Perl tradition and would probably make me more enemies than any
other solution.
So, faced with those choices, I've decided to do nothing for the
moment. Specificallly, I will NOT:
- Transform EOL characters in files I read generally.
- Change the definition of \n.
- Accept '/' as a path separator.
- Change the time() epoch to 1970.
Sorry that I sound a bit annoyed about this, but we've gone through these
discussions *WAY* too many times. If I wanted to cater to the tastes of an
early 70s operating system, I would probably also wear dark horn-rimmed
glasses, listen to the "Hair" soundtrack and burn my bra in public.
I WILL, however, go along with any effort that the Perl Porters come up with,
and I reserve the right to reassess my position on the above issues when I've
had practical experience with the side-by-site operation of MacOS and Rhapsody.
Ask me again in a year or so.
Matthias
- -----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri
"We all enter this world in the same way: naked; screaming; soaked in
blood. But if you live your life right, that kind of thing doesn't
have to stop there." -- Dana Gould
***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch