This patch hides all the old typeOfExpression, typeOfName, typeOfVariable, etc, and unifies them into a single type-class with an "astTypeOf" function. The type-class is currently named Typed, but that can easily be changed (it's only explicitly referred to in the Types module). The patch is essentially the type-class with a giant find-and-replace on the other modules.
This provides transformM, which we can build applyX (etc.) on top of:
it takes a set of functions, and applies them wherever they could
match in a data structure, without automatically recursing. This is
done using a four(!)-argument typeclass, drawing inspiration from
Biplate.
The resulting 25,000-line set of instances takes a little while to
compile...
Previously they had a list of the types they needed to generate
instances for. This patch adds some helper code that can be used to
list all the AST.* types in the AST automatically. The result is that we
should be able to add new types to the AST without needing to change the
generator code.
This also means that GenOrdAST is now generating *all* the instances of
Ord for the AST; previously the trivial ones were derived by the
compiler.
Paths.hs is now generated by the Makefile.am, so it can include paths.
As a bonus, this actually works, since we weren't previously installing the .pc
file anywhere...
The types get hairier, but the code is much simpler!
I've left {check,apply}DepthM{,2} there for now, but reimplemented them in
terms of the new combinators.
Fixes#58.
In particular, evalSimpleLiteral is now much nicer, and the error
messages should be a bit more comprehensible.
The signed types previously used a different version of fromRead that
passed an extra argument that it then didn't use; I've switched back to
the old version now, since it appears not to need it any more.
This is rather more expensive than the approach it was using, but it
does the right thing for things like "3 + 4(MYINT)" and "[3, 4(MYINT)]",
and the code's actually simpler.
This isn't the right behaviour, although it's closer: what it really needs to
do is to try to infer both sides in the current (or no) context, pick the more
specific type of the two inferred, then use that to redo the other one. Yuck!
This works the same way that it used to. I did experiment with actually
defining them as Procs and Functions in the normal way, but that'd require an
awful lot of special-casing later on, and would preclude support for multiple
types in the future, so I'll keep it this way for now.
This also changes the behaviour for array literals so that the inferred type of
the first item is used as the default for the rest. This satisfies all the
cgtests except for a test in cgtest59 which does "a IS [3, 4 (type)]:", which
I've never seen in a real program, and would require a bit more complication to
handle.
