Operators vs type operators

[j-hui]

I began to run some of the old unit tests, and found that the scanner test was failing because & was being lexed as TAmpersand rather than TOp "&".

In #14, I hard-coded the scanner test to expect TAmpersand instead, but this puts more of a strain on the parser to account for all these special operators as edge cases. At some point, we should enumerate all the type operators we expect to use, and make sure we are treating them consistently in the front-end.

I see three solutions:

1. A general, thorough solution is to just allow full-blast type-level operators, and just throw them to the same ParseOperators logic we're already using for expressions. Frankly, I think this is the most elegant, since most of the prior work on that can be reused. Then we can expose this as a feature for those maverick users who want their own notation for types. Of course, this is blocking on Syntax for specifying operator precedence and associativity #15.
2. We could have the parser explicitly also look for the TOp "&" token when parsing type expressions, or for TAmpersand when parsing expressions. But this doesn't scale well if we add more operators, not to mention it's not very elegant, so I'm hoping we don't adopt this solution. But this can be done immediately and temporarily.
3. We could rethink our grammar for type operators and designate a complentary set of tokens that can be used as type operators vs expression operators. If designed well, this could be beneficial to the reader, the same way that it is beneficial that types and data constructors are always upper case and type variables and variables are always lower case in Haskell; but if designed poorly, this could lead us toward something inscrutible.

As a side note, we should decide on what notation to use for the "reference" type operator (a pre-requisite of solution 3). I'm in favor of using a type operator rather than something alphanumeric since it's a built-in type hard-wired into our programming model, and will appear everywhere. For this, I default to the prefix & symbol but I can be persuaded otherwise.

[sedwards-lab]

Probably good enough to include a handful of the usual type operators (e.g., ->, [], &, maybe @ for scheduled) and leave it at that. More general type operators is an interesting idea, but I see a lot we should do before spending time on that. It's just syntactic sugar, anyway.