Parse unary plus corretly (i.e., by ignoring it when it's valid).

frog/leg/scanner/parser.dart

 // Copyright (c) 2011, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 /**
  * An event generating parser of Dart programs. This parser expects
  * all tokens in a linked list.
  */
 class Parser {
   final Listener listener;
@@ skipping 924 matching lines @@
         info = token.info;
         tokenLevel = info.precedence;
       }
     }
     return token;
   }
 
   Token parseUnaryExpression(Token token) {
     String value = token.stringValue;
     // Prefix:
-    if ((value === '!') ||
-        (value === '+') || // TODO(ahe): Being removed from specification.
-        (value === '-') ||
-        (value === '~')) {
+    if (value === '+') {
+      // Dart only allows "prefix plus" as an initial part of a
+      // decimal literal. We scan it as a separate token and then throws

[ahe, 2012/02/03 11:28:51]

throws -> throw

+      // it away here when we know that we have an unary plus, not a

[ahe, 2012/02/03 11:28:51]

"an unary" -> "a unary"

http://owl.english.purdue.edu/owl/resource/591/1/

+      // binary one.

[Lasse Reichstein Nielsen, 2012/02/03 13:30:17]

Comment updated.

+      Token next = token.next;
+      if (next.charOffset === token.charOffset + 1) {
+        if (next.kind === INT_TOKEN) return parseLiteralInt(next);

[ahe, 2012/02/03 11:28:51]

We shouldn't throw tokens away. Long term, it becomes a problem for IDEs.

Short term it would be better to throw the token away in the listener.

[Lasse Reichstein Nielsen, 2012/02/03 13:10:22]

I think we should throw it away in the listener in all cases. The language
doesn't contain a unary plus operator, so it shouldn't be in the AST either. We
can still link the number AST node to the appropriate Tokens.

We can also complain a little about having a lexical grammar that is ambiguous
(in itself, since it depends in the syntactical grammar): the characters "+0"
should be tokenized differently depending on the preceding token, e.g. ";" ("+0"
is one token) or "0" (two tokens). That's almost JavsScript bad :(

[ahe, 2012/02/03 13:19:11]

Unfortunately, that way of thinking is counter-productive for implementing IDE
features.

The more we accept and can represent, the better.
The Dart language grammar is not designed to be sane, easy to implement, or
unambiguous.

Purists may weep. I find it easier to accept that the world doesn't want
Smalltalk or Scheme and move on. C syntax is horrible.

[Lasse Reichstein Nielsen, 2012/02/03 13:30:17]

I'm not advocating throwing the character away, but I do think we should treat
it as a single number literal (comprised of two tokens). We don't parse "0x" of
a hex literal as a separate "prefix hex operator", so we shouldn't need parse
"+" of "+0" as a separate "prefix plus operator".

[ahe, 2012/02/03 13:41:10]

We could do that. I guess it would be limited to LiteralInt and LiteralDouble.

+        if (next.kind === DOUBLE_TOKEN) return parseLiteralDouble(next);
+      }
+      listener.recoverableError("Unexpected token '+'", token: token);
+      return parseUnaryExpression(next);
+    } else if ((value === '!') ||
+               (value === '-') ||
+               (value === '~')) {
       Token operator = token;
       // Right associative, so we recurse at the same precedence
       // level.
       token = parsePrecedenceExpression(token.next, POSTFIX_PRECEDENCE);
       listener.handleUnaryPrefixExpression(operator);
     } else if ((value === '++') || value === '--') {
       // TODO(ahe): Validate this is used correctly.
       Token operator = token;
       // Right associative, so we recurse at the same precedence
       // level.
@@ skipping 645 matching lines @@
     }
     listener.handleContinueStatement(hasTarget, continueKeyword, token);
     return expectSemicolon(token);
   }
 
   Token parseEmptyStatement(Token token) {
     listener.handleEmptyStatement(token);
     return expectSemicolon(token);
   }
 }