Home › Blogs › acer's blog

Parser Differences

acer's picture
Posted on 2010-01-12 17:21 By acer (Maple Rating 4 2066)
Categories:

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

Comments

1D vs Command Line

Comment on 2010-01-13 02:07 from Joe Riel (Maple Rating 4 1777)

Your penultimate example is surprising; it indicates that the Standard 1D parser differs from the command-line parser.  That is

(**) proc(x); local a; end proc;

is syntactically acceptable in command-line Maple.

syntactically acceptable?

Comment on 2010-01-13 02:49 from jakubi (Maple Rating 4 1582)

I get an error here:

    |\^/|     Maple 13 (IBM INTEL NT)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
> proc(x); local a; end proc;
Error, unexpected local declaration in procedure body
> quit
memory used=0.9MB, alloc=1.1MB, time=0.06

linux 64

Comment on 2010-01-13 13:15 from Joe Riel (Maple Rating 4 1777)

Interesting:

    |\^/|     Maple 13 (X86 64 LINUX)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
> proc(x); local a; end proc;
                                                 proc(x) local a;  end proc

or worrying...

Comment on 2010-01-13 13:22 from jakubi (Maple Rating 4 1582)

Do you think that this is a 64 bit issue? (later I will boot into Linux 32 and check).

In Linux 32

Comment on 2010-01-14 01:18 from jakubi (Maple Rating 4 1582)

I get also an error message:

    |\^/|     Maple 13 (IBM INTEL LINUX)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
> proc(x); local a; end proc;
Error, unexpected local declaration in procedure body

difference

Comment on 2010-01-14 02:50 from Joe Riel (Maple Rating 4 1777)

I realized why mine is different; it's not linux 64 specific.  My version enables a feature (some minor syntactic sugar) that isn't quite ready for public release.

acer's picture

clarification

Comment on 2010-01-13 12:12 from acer (Maple Rating 4 2066)

I can explain a little more what I mean when I state that the following is a bug.

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

In 1D Maple notation, the decimal point has a greater precedence in parsing than does the infix `.` multiplication operator. So the above example is actually implicit multiplication by 2. the floating-point value. So, really, this is just another implicit multiplication example.

The system has anomalies. Precedence is not merely an operator issue (see ?operators,precedence ), but is also a parsing issue. Where can one see it documented that the decimal point has a "greater parsing precedence" than does infix `.`, but less than infix `..`?

# In either entry mode, this gives a range
2..sin(x);

At the very least, this is a missing documentation bug (much like this ). Why doesn't ?syntax mention 2D Math's implicit multiplication, or link to a 2D Math syntax page?

While I'm at it, the ?syntax help-page describes the ambiguity of a^b^c and the need for brackets, in 1D Maple notation where it makes sense. But the ?operators,precedence help-page has the same explanation in 2D Math notation, where it doesn't make any sense.

acer

Explanation of parser differences

Comment on 2010-01-14 15:27 from pchin (Maple Rating 3 200)

Thanks for the thorough post, acer. I'll go through each of the cases you mentioned.

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

This is a known bug. I realize it has been reported before. We're not ignoring it, but it is somewhat difficult to fix and not of the highest priority right now, because there is a workaround available (using proc syntax instead of the arrow operator). We will try to deal with this as soon as possible or make a note of it in our documentation, as has been suggested elsewhere.

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

This is a bug.

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);

Both of the above examples are a consequence of 2-d input's implicit-multiplication rules.

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

This is, as you observed, by design. When you enter != or paste it, it immediately turns into <>, so at least users are not misled into thinking it has a different meaning.

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

This again is an instance of implicit multiplication. You are right in that the parsing rules regarding the decimal point vs. the dot operator should be explained more clearly in the documentation. I will add that request to our bugs database.

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

This is a bug in the 2-d parser.

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);

This also looks like a bug.

I'll check our database to see if these bug reports are already present, and if not, I will add them. If you've submitted any of them already, please let me know. Thanks.

Paulina Chin
Maplesoft

acer's picture

thanks

Comment on 2010-01-14 15:58 from acer (Maple Rating 4 2066)

Thanks, so it seem like the differences are either bugs, or implicit multiplication, or the following singleton,

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

  "This is, as you observed, by design. When you enter != or
   paste it, it immediately turns into <>, so at least users
   are not misled into thinking it has a different meaning." (pchin)

Even better than turning this into m <> n would be to leave it as m! = n which was already a meaningful mathematical syntax in Maple for many releases. It's wrong to change it, on several different levels.

  • It already meant something well understood mathematically, for many Maple releases.
  • It's rather gratuitous clobbering of Maple 1D syntax with some non-universally understood (C...) syntax.
  • It creates a difference between the parsers, which should be avoided unless it brings a really significant functionality improvement (which this does not). See Jacque's characterization in the link.
  • It will incorrectly rewrite any piece of Maple code containing it, that anyone finds on the web or in course notes and pastes into Standard with its default 2D Math mode.

acer

Will consider

Comment on 2010-01-14 16:15 from pchin (Maple Rating 3 200)

We'll definitely consider your comments, acer, and we'll review the current design for parsing m!=n to see if it's reasonable. Can't promise anything, though. Changing the interpretation will have some consequences, so we'll have to think it over carefully.

Paulina

worth considering

Comment on 2010-01-15 00:38 from PatrickT (Maple Rating 4 554)

 

It will incorrectly rewrite any piece of Maple code containing it, that anyone finds on the web or in course notes and pastes into Standard with its default 2D Math mode.

 

I strongly agree, in my view this comment applies very generally -- standard/2D ought to be as little different as classic/1D as possible. Else standard/2D and classic/1D should have very different names. The potential confusion between the two is not just a nuisance, it's impeding, believe me, the growth of Maple products. Users want as much compatibility as possible.

As I shun standard, I'm increasingly marginalized and increasingly looking for alternatives. For instance, I no longer use Maple for plots, because the classic plot graphical functions have been neglected relative to standard (I use pstricks and have occasionally gone back to excel/openoffice). The more new functionalities that don't work in classic are introduced in standard, the less Maple has to offer me...

acer's picture

defaults

Comment on 2010-01-15 02:38 from acer (Maple Rating 4 2066)

Please keep in mind that one can set preferences in Standard so that all File->New sheets are opened as Worksheets instead of Documents, and with the input mode set to 1D Maple notation instead of 2D math.

So, the issue of Standard vs Classic is not really the same as the issue of 2D vs 1D input modes.

acer

yes and no

Comment on 2010-01-15 06:33 from PatrickT (Maple Rating 4 554)

of course you are right that preferences may be set, but 1) in environments in which you do not have the ability to save preferences, it's very tedious to reset each time, 2) standard maple loads more slowly than classic, requiring an extra five to ten seconds on my dual-core state of the art machine. Assuming I open about 20 worksheets per hour of Maple use, that's over 3 minutes of time wasted, time I could more profitably use to type one message like this one.

saved preferences

Comment on 2010-01-15 08:53 from pagan (Maple Rating 4 451)

The preferences of New->Worksheet (not Document) and 1D (not 2D) input are both preferences that can be saved in Standard using Tools->Options from the main menubar. (Sorry if I misunderstood, but you seemed to be indicating in your 1) that such preferences could not be saved.)

I once knew a guy who did all his editing in xemacs, which used to start slowly way back when. He'd close it after each finished document. He'd even fire it up more than once in order to edit multiple files concurrently. ...Anyway, I guess the "ideal" intended use is that Maple can be opened, and kept open, for the day (say). I don't know how well such practice would do with Standard, whether memory leaks and whatnot would force periodic relaunching. A program intended for multiple documents should either start fast, or be rock solid and leak free.

Me, I am content to use Standard for worksheets, and keep it open for longer than just the single first sheet's use. When I want really fast access I use the commandline interface since that is fastest and leanest.

Correction

Comment on 2010-01-18 14:57 from pchin (Maple Rating 3 200) 
A correction to my previous post: 

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

This is not a bug. In 2-d math, the backslash is not used as a line continuation character but it is used as the set minus operator. This is one of the situations where there is an intended difference between the two parsers. I'll add a note to the documentation if it's not already mentioned in the help pages.

Paulina
 

Axel Vogt's picture

not a bug ...

Comment on 2010-01-18 16:02 from Axel Vogt (Maple Rating 4 1462)

Formally nothing is a bug, if a docu tells it.

But who ever seriously thinks that for users switching from one to the other it is bearable to check each input characterwise?

I will never understand that attitude (sorry, please do not take it personally)

acer's picture

suggestion

Comment on 2010-01-18 16:41 from acer (Maple Rating 4 2066)

I believe that I can say, based on these replies, that the current justification of this particular parser difference is not easy (for any of us) to remember. That is telling.

But, also, cannot the 2D Math parser be made nicer here? The posted example is about pasting plaintext 1D input into Standard when in 2D input mode. In 1D Maple notation, the backslash does not mean set-minus. So why cannot the 2D Math parser recognize it as having its 1D Maple notation meaning and parse it appropriately? Why should it parse it using the 2D Math syntax? Why can't the GUI & 2D Math parse it in the same way that the 1D parser does, and so for this example result in obtaining a concatenated long line?

There are lots of examples where the 2D Math parser will interpret pasted 1D input in a special way, and adjust accordingly. Here is one nice example.

a/b/c;

If the above code is pasted in, while in 2D Math input mode, it gets parsed like a*(1/b)*(1/c). In other words, it gets parsed quite differently than if one types those symbols in by hand. So the 2D Math parser is quite capable of distinguishing pasted 1D plain text.

Why couldn't the 2D Math parser be taught how to handle backslash in pasted 1D input as the line-continuation character (when valid, and not as an escape symbol inside a string)?

acer

acer's picture

new topic?

Comment on 2010-01-15 09:17 from acer (Maple Rating 4 2066)

As fascinating as the topic of rationale for personal choice of Maple interface is, perhaps it could be started in a new blog or forum topic? I feel confident that other people might have things to add on that. But it doesn't really pertain to 1D vs 2D parsing.

cheers,
acer

sure

Comment on 2010-01-15 09:25 from PatrickT (Maple Rating 4 554)

sorry acer for hijacking your thread!

Thanks for the suggestion

Comment on 2010-01-18 17:39 from pchin (Maple Rating 3 200)

Thanks for the suggestion, acer. Indeed, I was rather hasty with my reply. I meant to explain that the backslash character has a different meaning in 2-d math, but we will look at the situation to see if can be improved in any way. I haven't had the chance to test this out thoroughly, but in some cases (e.g. when output in Maple with the line continuation character is copied and pasted back into an input line), the input is parsed as expected. The backslash, entered directly, has a different meaning in 2-d math from 1-d math, and that is unlikely to change, but you are right that some of the copy-paste situations might be fixable.

Paulina

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
}