This makes sure that we catch all leftover instances of using SYB to do generic operations that we should be using Polyplate for instead. Most modules should only import Data, and possibly Typeable.
They are now recursed into with no type context, then afterwards the type is deduced. This seems to be how they were meant to work, and is also much faster than what I was doing.
This patch follows on from the previous change to the parser. When it spots a function-call, it looks for operators and treats them differently.
It keeps a stack of operators in scope (csOperators in CompState), and when an operator is used, it searches the stack (with all old definitions masked out) for operator definitions to resolve to.
The way it chooses which operator to use in the presence of overloadings (e.g. + on INT vs + on INT32) is simply to try them all. If one matches, it uses that. If none, or more than one match, it gives an error. This makes the code simple and seems logical, but I'm not totally confident if this is the required behaviour for resolving overloaded operators.
This may seem like an odd change, but it simplifies the logic a lot. I kept having problems with passes not operating on externals (e.g. functions-to-procs, adding array sizes, constant folding in array dimensions) and adding a special case every time to also process the externals was getting silly.
Putting the externals in the AST therefore made sense, but I didn't want to just add dummy bodies as this would cause them to throw up errors (e.g. in the type-checking for functions). So I turned the bodies into a Maybe type, and that has worked out well.
I also stopped storing the formals in csExternals (since they are now in csNames, and the tree), which streamlined that nicely, and stopped me having to keep them up to date.
Previously, such a function was an IntrinsicFunctionCall inside one expression of an ExpressionList, which the type-checker rejected. I've had to add a new constructor to ExpressionList, and I've quickly hacked together the line in the C backend to make it work -- but it does seem to work.
In actual parameters (checking against the formal type), abbreviations (checking against the inferred/specified destination type), and inputs (including inside ALTs) and outputs, direction specifiers are automatically added where needed. With all the other changes, this seems to compile all the occam 2 cgtests, and cgtest87 (which tests directions) as well as Adam's tests so I'm fairly confident that it was the right thing to do.
This is mostly straightforward: modify the parser to allow direction
decorators in the right places, and extend the type checker to match.
There's some slight awkwardness in that some of the Types functions
have to perform the same checks as the type checker (e.g. directing a
non-channel), so I've tidied up their error messages a bit.
At the backend, I've just added a little pass to strip out all the
DirectedVariables, since the other backend passes don't handle them
gracefully. From the occam/C point of view this is fine, but I'm not
sure if it's going to cause problems for C++.
