Adjusted grammar in spec to handle nullability token `?`.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
 {4th edition draft}\\
@@ skipping 689 matching lines @@
 
 \LMHash{}
 A {\em required formal parameter} may be specified in one of three ways:
 \begin{itemize}
 \item By means of a function signature that names the parameter and describes its type as a function type (\ref{functionTypes}).  It is a compile-time error if any default values are specified in the signature of such a function type.% explain what the type is in this case? Where is this described in general?
 \item As an initializing formal, which is only valid as a parameter to a generative constructor (\ref{generativeConstructors}). % do we need to say this, or anything more?
 \item Via an ordinary variable declaration (\ref{variables}).
 \end{itemize}
 
 \begin{grammar}
-{\bf normalFormalParameter:}functionSignature;
+{\bf normalFormalParameter:}functionSignature `?'?;
       fieldFormalParameter;
       simpleFormalParameter
  .
 
 {\bf simpleFormalParameter:}declaredIdentifier;
       metadata identifier
     .
 
 {\bf fieldFormalParameter:}
    metadata finalConstVarOrType? \THIS{} `{\escapegrammar .}' identifier formalParameterList?
@@ skipping 92 matching lines @@
 A {\em class} defines the form and behavior of a set of objects which are its {\em instances}.  Classes may be defined by class declarations as described below, or via mixin applications (\ref{mixinApplication}).
 
 \begin{grammar}
 {\bf classDefinition:}
 metadata \ABSTRACT{}?  \CLASS{} identifier typeParameters? (superclass mixins?)? interfaces? \\
        `\{' (metadata classMemberDefinition)* `\}';
 
 metadata \ABSTRACT{}?  \CLASS{} mixinApplicationClass
     .
 
+{\bf classDenotation:}
+    className typeArguments?

[Lasse Reichstein Nielsen, 2017/05/30 10:52:30]

className is equivalent to typeName, so this could be
  typeName typeArguments?

Also, that means that type could be declared as

  type  ::= className `?'?


So, maybe rename className to typeName so:

type ::= typeName `?'?
typeName ::= type typeArguments?
type ::= qualified
typeList ::= (comma separated types)
typeNameList ::= (comma separated typeNames)

(I know that classDenotation *should* refer to a class, but that's not handled
at the syntactic level, it's just the name of a type).

+  .
+
+{\bf className:}
+    qualified
+  .
+
+{\bf classDenotationList:}
+      classDenotation (`,$\!\!$' classDenotation)*
+    .
+
 {\bf mixins:}
-  \WITH{} typeList
+  \WITH{} classDenotationList
   .
 
 {\bf classMemberDefinition:}declaration `{\escapegrammar ;}' ;
        methodSignature functionBody
     .
 
 {\bf methodSignature:}constructorSignature initializers?;
       factoryConstructorSignature;
       \STATIC{}? functionSignature;
       \STATIC{}? getterSignature;
@@ skipping 596 matching lines @@
 }
 
 \paragraph{Redirecting Factory Constructors}
 \LMLabel{redirectingFactoryConstructors}
 
 \LMHash{}
 A {\em redirecting factory constructor} specifies a call to a constructor of another class that is to be used whenever the redirecting constructor is called.
 
 \begin{grammar}
 {\bf redirectingFactoryConstructorSignature:}
-      \CONST{}? \FACTORY{} identifier (`{\escapegrammar .}' identifier)? formalParameterList `=' type (`{\escapegrammar .}' identifier)?
+      \CONST{}? \FACTORY{} identifier (`{\escapegrammar .}' identifier)? formalParameterList `=' classDenotation (`{\escapegrammar .}' identifier)?
     .
 \end{grammar}
 
 \LMHash{}
 Calling a redirecting factory constructor $k$ causes the constructor $k^\prime$ denoted by $type$ (respectively, $type.identifier$) to be called with the actual arguments passed to $k$, and returns the result of $k^\prime$ as the result of $k$.  The resulting constructor call is governed by the same rules as an instance creation expression using \NEW{} (\ref{instanceCreation}).
 
 \commentary{
 It follows that if $type$ or $type.id$ are not defined, or do not refer to a class or constructor, a dynamic error occurs, as with any other undefined constructor call. The same holds if $k$ is called with fewer required parameters or more positional parameters than $k^\prime$ expects, or if $k$  is called with a named parameter that is not declared by $k^\prime$.
 }
 
@@ skipping 257 matching lines @@
 \begin{itemize}
 \item $C$ is \code{Object}, which has no superclass. OR
 \item Class $C$ is  deemed to have an \EXTENDS{} clause of the form \code{\EXTENDS{} Object}, and the rules above apply.
 \end{itemize}
 
 \LMHash{}
 It is a compile-time error to specify an \EXTENDS{} clause for class \code{Object}.
 
 \begin{grammar}
 {\bf superclass:}
-      \EXTENDS{} type
+      \EXTENDS{} classDenotation
     .
 \end{grammar}
 
 %The superclass clause of a class C is processed within the enclosing scope of the static scope of C.
 %\commentary{
 %This means that in a generic class, the type parameters of the generic are available in the superclass clause.
 %}
 
 \LMHash{}
 The scope of the \EXTENDS{} and \WITH{} clauses of a class $C$ is the type-parameter scope of $C$.
@@ skipping 120 matching lines @@
 \subsection{ Superinterfaces}
 \LMLabel{superinterfaces}
 % what about rules about classes that fail to implement their interfaces?
 
 \LMHash{}
 A class has a set of direct superinterfaces. This set includes the interface of its superclass and the interfaces specified in the \IMPLEMENTS{}  clause of the class.
 % and any superinterfaces specified by interface injection (\ref{interfaceInjection}).  \Q{The latter needs to be worded carefully - when do interface injection clauses execute and in what scope?}
 
 \begin{grammar}
 {\bf interfaces:}
-      \IMPLEMENTS{} typeList
-    .
+    \IMPLEMENTS{} classDenotationList
+  .
 \end{grammar}
 
 \LMHash{}
 The scope of the \IMPLEMENTS{} clause of a class $C$ is the type-parameter scope of $C$.
 
 \LMHash{}
 It is a compile-time error if  the \IMPLEMENTS{}  clause of a class $C$ specifies a type variable as a superinterface. It is a compile-time error if  the  \IMPLEMENTS{} clause of a class $C$ specifies an enumerated type (\ref{enums}),  a malformed type or deferred type (\ref{staticTypes}) as a superinterface.  It is a compile-time error if the \IMPLEMENTS{} clause of a class $C$ specifies type \DYNAMIC{} as a superinterface. It is a compile-time error if  the  \IMPLEMENTS{} clause of a class $C$ specifies  a type $T$ as a superinterface more than once.
 It is a compile-time error if the superclass of a class $C$ is specified as a superinterface of $C$.
 
 \rationale{
@@ skipping 167 matching lines @@
 
 \LMHash{}
 A mixin may be applied to a superclass, yielding a new class. Mixin application occurs when a mixin is mixed into a class declaration via its \WITH{} clause.  The mixin application may be used to extend a class per section (\ref{classes}); alternately, a class may be defined as a mixin application as described in this section.   It is a compile-time error if the \WITH{} clause of a mixin application $C$ includes a deferred type expression.
 
 
 \begin{grammar}
 {\bf  mixinApplicationClass:}
         identifier typeParameters? `='  mixinApplication `{\escapegrammar ;}' .
 
 {\bf mixinApplication:}
-     type mixins interfaces?
+      classDenotation mixins interfaces?
     .
 \end{grammar}
 
 \LMHash{}
 A  mixin application of the form  \code{$S$ \WITH{} $M$;} defines a class  $C$ with superclass  $S$.
 
 \LMHash{}
 A  mixin application of the form  \code{$S$ \WITH{} $M_1, \ldots, M_k$;} defines a class  $C$ whose superclass is the application of the mixin composition (\ref{mixinComposition}) $M_{k-1} * \ldots * M_1$ to $S$.
 
 \LMHash{}
@@ skipping 297 matching lines @@
     .
 \end{grammar}
 
 \begin{grammar}
 {\bf primary:}thisExpression;
       \SUPER{} unconditionalAssignableSelector;
       functionExpression;
       literal;
       identifier;
       newExpression;
-      \NEW{} type `\#' (`{\escapegrammar .}' identifier)?;
+      \NEW{} classDenotation `\#' (`{\escapegrammar .}' identifier)?;
       constObjectExpression;
       `(' expression `)'
     .
 
 \end{grammar}
 
 \LMHash{}
 An expression $e$ may always be enclosed in parentheses, but this never has any semantic effect on $e$.
 
 \commentary{
@@ skipping 902 matching lines @@
 
 
 \subsubsection{ New}
 \LMLabel{new}
 
 \LMHash{}
 The {\em new expression} invokes a constructor (\ref{constructors}).
 
 \begin{grammar}
 {\bf newExpression:}
-\NEW{} type (`{\escapegrammar .}' identifier)? arguments
-.
+    \NEW{} classDenotation (`{\escapegrammar .}' identifier)? arguments
+  .
 \end{grammar}
 
 \LMHash{}
 Let $e$ be a new expression of the form
 
 \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ or the form
 
 \NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 %It is a runtime type error if
@@ skipping 96 matching lines @@
 
 
 \subsubsection{ Const}
 \LMLabel{const}
 
 \LMHash{}
 A {\em constant object expression} invokes a constant constructor (\ref{constantConstructors}).
 
 \begin{grammar}
 {\bf constObjectExpression:}
-\CONST{} type ('{\escapegrammar .}' identifier)? arguments
-.
+    \CONST{} classDenotation ('{\escapegrammar .}' identifier)? arguments

[Lasse Reichstein Nielsen, 2017/05/30 10:52:30]

' -> ` 
maybe?

+  .
 \end{grammar}
 
 \LMHash{}
 Let $e$ be a constant object expression of the form
 
 \CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 or the form  \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. It is a compile-time error if $T$ does not denote a class accessible in the current scope.  It is a compile-time error if $T$ is a deferred type (\ref{staticTypes}).
 
 \commentary{In particular, $T$ may not be a type variable.}
@@ skipping 3604 matching lines @@
 }
 
 \subsection{Static Types}
 \LMLabel{staticTypes}
 
 \LMHash{}
 Static type annotations are used in variable declarations (\ref{variables}) (including formal parameters (\ref{formalParameters})), in the return types of functions (\ref{functions}) and in the bounds of type variables.  Static type annotations are used during static  checking and when running programs in checked mode. They have no effect whatsoever in production mode.
 
  \begin{grammar}
 {\bf type:}
-      typeName typeArguments?
+      typeName typeArguments? `?'?
     .
 
 {\bf typeName:}
       qualified
     .
 
 {\bf typeArguments:}
       '<' typeList '>'

[Lasse Reichstein Nielsen, 2017/05/30 10:52:30]

The quotes here look wrong, should they be `<' and `>' ?

     .
 
 {\bf typeList:}
       type (',' type)*

[Lasse Reichstein Nielsen, 2017/05/30 10:52:30]

Add $\!\!$ here too?

     .
  \end{grammar}
 
 \LMHash{}
 A Dart implementation must provide a static checker that detects and reports exactly those situations this specification identifies as static warnings and only those situations. However:
 \begin{itemize}
 \item Running  the static checker on a program $P$ is not required for compiling and running $P$.
 \item Running the static checker on a program $P$ must not prevent successful compilation of $P$ nor may it prevent the execution of $P$, regardless of whether any static warnings occur.
 \end{itemize}
 
@@ skipping 840 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------