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.
Unfortunately there appears to be exactly one place you can do this, and it
turns out to be inside inferTypes (because you need to know the type of c
completely, and you can't type-infer x until you know if it's a tag or a
variable). It's definitely nicer than doing it in the parser, though.
I've also started adding "-- AMBIGUITY" comments in the parser.
This makes sure that literals produced by the constant evaluator will never
contain UnknownDimension. The change looks a lot more complex than it really
is; it already carried the type "downwards", and most of this is just making it
carry it back up to where the A.Literal is being constructured.
