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.
This fixes the problem with PROCs complaining that one munged version of the record name was not the same as another.
This will cause problems if two different record definitions for the same name are visible in the same file.
I changed a little bit of the code, but mainly the tests. Several of the remaining failures are actually real failures, so I need to dig through the rest carefully. A lot are failing because the C++ backend is broken.
Also known as communication semantics, I think. The pass adds an extra channel parameter per mobile (perhaps in future this could be a single extra channel?) that is used to send back the mobile value, and hacked the backend so that the communications to receive these mobiles are done in the right place (after the processes have been run, but before waiting on the barrier for them to complete).
cgtest83 now compiles, runs and passes without a segfault.
Surprisingly, the generated code seems to be compiled by GCC without warnings. Array subscripts are currently unimplemented (a star, i.e. equivalent of subscript 0) is used wherever there should be a subscript.
The new mechanism is based on working out the C type of the original variable/abbrev-mode, the C type of the desired variable/abbrev-mode, and works out how many *s or &s to insert to coerce it to the right type.
Procs that are in csParProcs are now generated with the correct calling
convention directly, rather than having a second wrapper function generated
around them.
Most of this is mechanical: changing function names, and carrying the "wptr"
argument around. I've made the code for computing Expressions from Structureds
a bit more generic too.
The only complex bit is the handling of PAR processes, which I'm not very happy
with at the moment; they used to use the normal C calling convention, but now
you need to pack the arguments into the workspace. I'm handling this at the
moment by generating wrapper functions that do the unpacking, but it would be
better in the future to make the wrapper PROCs that we already generate have
the right interface.
This won't work for programs that use any of the top-level channels yet, since
there are no handlers for them.
