Re: [MacPerl] When is \r really \n in MacPerl!?

[Matthias Ulrich Neeracher <neeri@iis.ee.ethz.ch>]

Mark,

you have certainly every right to state your opinion, but I'd prefer if you
toned down your rhetoric a bit.

"Mark F. Murphy" <markm@mail.tyrell.com>
In message <v0311072cb1061f2567c3@[24.1.142.24]> you write:
>At 8:43 PM -0500 2/9/98, Paul J. Schinder wrote:
>>Excuse me?  What makes you thing that \n and \r have fixed values?  (Hint:
>>Kernighan and Ritchie is no longer the standard.)
>>
>>The results of your script are exactly right for MacPerl, and it makes
>>utter sense to do this under MacOS.
>
>I do plenty of development on the Mac... and it doesn't make "sense" to
>switch around common escape characters that are pretty well defined in the
>ascii namespace.
>
>What makes "sense" is for the a Mac program to understand what \r and \n
>are and to do the right thing for the end user's visual result.

Right. My understanding of \r and \n is based on the C standard, which says
that:

 - \n is "new line". Moves the active position to the initial position of the
   next line. When writing to a file, this should generate the preferred line
   terminator on a platform (\015 on a Mac, \012 on Unix).
 - The *name* of \r is indeed based on "carriage return", BUT, the standard
   *requires* that \r and \n be internally coded with different values, so it
   makes sense to code \r as whichever of \015 and \012 which is not taken up
   by \n.

Thus, a correct Mac implementation of C *has* to write \015 for text output
streams when it sees "\n". It would be free to choose the internal
representation, but representing it internally the same way as externally
certainly makes some sense. My interpretation of Perl's \n is that it should do
whatever C \n on that platform does.

>Changing the meaning in a programming language can be disastrous.

Right. That's why it is important that \n is defined as \015 on the Mac.

>\r in the Perl books says it is a "carriage return"...

\r is, by virtue of the C standard, a rather ill defined escape sequence. It's
better to proceed from the definition of \n.

>One does not expect to ask for a "carriage return" character via the escape
>sequence \r only to get a 0x0A!

Most people do not expect all that much from \r anyway, and if they do, they
shouldn't.

However, a Perl implementation would definitely be broken if

        print "\n";

did not generate a newline.

>It's *not* right for MacPerl... it's not *right* for MacOS.

It's right for both.

>Of course, I've been down this similar path on this mailing list before and
>I already know what will happen.

All the more reason to appeal to reason instead of using inflammatory
rhetoric, then. You don't expect me to break 6 years of MacPerl scripts just
because you threw a temper tantrum, do you? :-)

>There will be a bunch of people proclaim how MacPerl does it the Mac way

Yes it does.

>The sad part is that MacPerl *could* do the right thing on the Mac.

But it does.

>It could recognize a perl script to have DOS, Unix, or Mac line endings.

That is one feature which is not currently implemented and which, for the
record, I have always supported. However, this feature firmly belongs in the
Perl *core* and every time I suggest this to the core Perl porters group, I
find myself outvoted.

>It could print out a newline to it's screen as a CR.

It does.

>Most other language based products do so on the Mac

Most *text editors* support reading sub-Macintosh text files and writing
whatever format they found. *Languages* in general don't support switching text
separator formats (except for MacTcl). Metrowerks C, which was designed back
when Symantec still dominated Mac C compilers, has a compatibility mode which
switches internal and external representations on \n and \r, but not switchable
at runtime.

>MacPerl isn't flexible...

Then, by all means, either

 - get a tool which meets your goals of flexibility
 - or modify MacPerl to your liking. Source code is available, after all.

>it just cheats by tweaking well defined things around.

No, it implements well defined concepts in a straightforward manner, which may
appear twisted to users with twisted minds :-)

Matthias

-----
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
  "Tossing around Slavic swearwords?  Tsk tsk.  Nekulturny peasants."
                                      -- Paul J. Zanca <pjz@sccsi.com>
















***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch