Broken syntax for nullary constructors

[rolyp]

The following parses incorrectly without the brackets around Nil:

      concat 
         (Nil)
         (map (map transpose) (axis (length rects') width))

Could use a more Haskell-like (function-like) syntax for constructors, but need to consider the fact that constructors are not yet first-class. If we made constructors first-class, we could use #327 to allow the user to write infix : instead of Cons, which would leave us with array syntax very much like PureScript, although it's not clear how to make that work in patterns. I would probably then drop the old [x, …xs] notation from the TypeScript implementation.

Open questions (not all necessarily related to this problem):

• should the syntax be "applicative", i.e. Cons e e’ rather than Cons(e, e’)?
• relatedly, should constructors appear curried: should Cons and Cons e be values?
• can we define constructors as infix (or provide infix synonyms)?
• do we need “friendly” list syntax [e, e', e'']

For now what we need is a simple, reasonably familiar design that also leaves us open to improvements in the future. Current proposal:

• distinguish constructors from identifiers by case, as we did previously (and as per Haskell) -- makes it easy to distinguish pattern variables from nullary constructors
• treat constructor names as identifiers that resolve to operators (primitives, not closures) - then "applicative" constructor parsing just falls out -- no: retain current grammar, but at runtime permit unsaturated constructor expressions, which will then be "applicable" (but which won't themselves be interpreted as application chains)
• generalise existing primitives infrastructure to work with (n + 1)-ary operators
• make constructors first-class (no need to unify with primitives, though):
  • represent partially applied constructors as unsaturated constructor values
    • constructor name evaluates to constructor value with zero arguments
    • allow such things to be applied until saturated
  • forward-slicing: annotation on (partial) constructor value is α argument to eval conjoined with annotation on partial constructor being applied (when saturated, consistent with previous monolithic approach)
• uniform apply interface to Unary and Binary, so the Binary implementation can take care of creating the PartialApp – no longer required
• missing verification of constructor signatures against data types (not responsibility of parser):
  • access to constructor signatures from data type definitions
  • constructor argument list matches arity of constructor
  • constructor pattern parameters matches arity of constructor
  • domain of a constructor eliminator is set of summands of the same data type
• Cons as infix :
  • define a pattern syntax analogous to expression syntax: an “operator tree” where
    • branches are binary infix constructors
    • leaves are “application chains” where the symbols in the function position are constructor names
  • operator definitions to include associativity as well as precedence
• undefined join of partial eliminators should be fatal, rather than cause backtracking