There was some recent discussion about Maple's Standard GUI having two parsers. (See here, and its parent.)

I've been accumulating a list of some differences between the parsers of 2D Math and 1D Maple notation, for the same given pasted input.

In particular, I'm interested here in differences in the parsing that occurs when typed plaintext gets pasted into the Standard GUI (in a Worksheet, say) in either of those two entry modes.

The idea in the code below, is to sweep it out with the mouse, and then paste directly into a Worksheet. The entry mode in the Worksheet can be toggled easily, for comparison. (On Linux, it toggles using the F5 key.)

I'm interested in that particular usage because it is common, and clearly defined. Lots of Maple input is entered on Mapleprimes as plaintext. Lots of Maple input exists in 1D form in worksheets on the web. 2D Math cannot really be expressed and copied outside of Maple, except as images with 1D alt-tags. Hence plaintext is a form in which the Maple language(s) continue to be communicated. So differences in how that gets parsed, in the two modes, is important.

Some of these are variations on a theme, illustrating the typical circumstances.

restart:
# valid in 1D but not in 2D
f:= x -> if x < 0 then a else b end if;

restart:
# valid in 1D but not in 2D
x := 12.34567\
89012345;

restart:
# works differently in 1D and 2D
sin (x);

restart:
# works differently in 1D and 2D
f := proc (x)
  x^2;
end proc:
f(3); f (3);

This next one is troublesome. Maple's 2D Math doesn't need C syntax, when 1D Maple notation doesn't have it. The old, usual Maple syntax of <> for not-equals is good enough. Introducing this was a design mistake.

restart:
# works differently in 1D and 2D
m!=n;

This next one should be considered a bug.

restart:
# valid in 2D but not in 1D
2.sin(x);

restart:
# valid in 2D but not in 1D
f := proc(x);
local a,b,c;
a:=x^2;
end proc;

This next one is a 2D Math parser bug, rather than a difference per se. But I'll mention it anyway, since it illustates how the parser can get muddled as the cursor gets moved around an input.

restart:
# bug in 2D
# first enter this in 2D mode, but don't Return
<|>(7);
# now wrap the <|> in ` name quotes, using the arrow
# keys to move the input cursor around. The result is not the same as before.
`<|>`(7);

acer