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