Status update.

[Austin Seipp]

> The following changes are near future goals:
>   * replace our built-in Haskell parser with haskell-src-exts.

I've been *really* busy with finals and various university stuff, so I
haven't had a chance to really tinker around with replacing the happy
parser with haskell-src-exts, but I'm getting around to it when I
can. Right now, LHC can accept just about any haskell98 program it
seems - until we can rewrite the typechecker to deal with the various
extensions that haskell-src-exts supports (notable ones: GADTs, ATs
and fundeps I suppose) we will have to have the compiler throw an
error upon their appearence, I guess.

>   * return to pure grin ideals. All indirections must be removed.

Is there a reason why eval is not inlined in the example you showed
earlier on this mailing list? From my reading of the Boquist papers,
the Heap points-to analysis is the control flow analysis for GRIN
code, and it gives a safe subset of the nodes that can be present when
inlining each call to eval. With the result of the heap points-to
analysis and other info it's possible to do further optimizations at
the call site (like determining exactly which node is present.) Can
you see a reason why we're not doing things like this currently?

>   * write a grin garbage collector. I believe it's possible to write a
> GC for grin that is agnostic about the target language (ISO C, in our
> case).

I think it's reasonable to have a simple but usable garbage collector
written in C that can be linked in with the resulting .c file
generated (or, perhaps, we should simply inline the GC code into every
.c file generated like lhc does already, since this stuff is generated
per-program.) Of course, dealing with platform idiosyncracies could be
a slight annoyance, but we will need to have further discussion about
how we should approach this issue before it happens anyway.

Austin