Re: Carriage return
- To: mathgroup at yoda.physics.unc.edu
- Subject: Re: Carriage return
- From: David Withoff <withoff>
- Date: Fri, 1 May 1992 11:44:54 -0500
Kjell Blotekjar writes:
> What is the rule used
> for handling carriage returns?
On the Macintosh, entire cells are sent to the kernel as input. The kernel
reads one line at a time from the cell until it has a complete expression,
evaluates that expression, and repeats the process until the end of the cell.
> Why not just neglect carriage returns?
Carriage returns are treated as either the end of an expression (if the
expression is complete), as blank space if there is a pending operation,
or as multiplication if there is no pending operation. I assume
that "neglect carriage returns" means that the end-of-expression
carriage returns would be treated as multiplication. This is certainly
a possibility, but it would change many things. For example
x = 1
y = 2
z = x + y
would then behave as the single assignment x=((1*y)=((2*z)=(x+y))) rather
than three separate assignments as it does now. (The latter input gives
an error.)
Personally, I think a better alternative is to have fewer carriage returns
interpreted as multiplication, rather than more. It is quite reasonable,
for example, to remove the ambiguity entirely by inserting asterisks to
indicate multiplication and semicolons to indicate the end of an expression:
x = 1 ;
y = 2 ;
z = x + y
or
x = 1 *
y = 2 *
z = x + y
Although I very much like the fact that Mathematica interprets certain
types of space as multiplication, explicit asterisks are often needed
to remove ambiguity, and in many computer languages they are required.
> The real bad thing is that in some cases Mathematica does not
> understand input which is generated by Mathematica itself. It
> has happened several times when I have used the command Copy
> Output From Above to generate an unformatted input cell from a
> rather long output, that Mathematica has interpreted the input
> erroneously, because of carriage returns. (This happened with
> version 1.2. I do not have enough experience with 2.0 yet).
In earlier versions there is a bug in the line breaking code that, under
fairly intricate conditions, leads to line breaks that are subsequently
interpreted incorrectly as expression separators. The bug rarely shows up
in practice, which is why it wasn't discovered earlier, but it is nevertheless
a serious problem, especially when working with large expressions. Changes
in the latest release will (I hope!) solve the problem.
Dave Withoff
withoff at wri.com