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.
This is looking at array dimensions in literals. By this point unknown
dimensions should have been inferred; if they haven't, I'd rather it blew up
here than caused bizarre behaviour later on.
(This is a good candidate for a property check.)
This means you don't have to have folded constants throughout the tree/state in
order to evaluate them, which makes the early passes less awkward to manage.
