Status update.

[Lemmih]

On Mon, Dec 8, 2008 at 9:54 PM, Austin Seipp <mad.one at gmail.com> wrote:
>> 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.

There is no rush.

> 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.

I found a parsing bug when I tried to compile 'pretty' from hackage
(test case has been added to the regression suite). We'll probably
find more corner cases as we compile more packages.

>>   * 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?

I asked John and he said that large case expressions could often be
slower than an indirect call. While this may be true, I do not believe
we should discard the information available through points-to
analysis. As it is now, we don't do any control flow analysis. As you
correctly pointed out, this makes it impossible to take advantage of
most GRIN optimizations. We can always change the GRIN->C compiler to
use indirect calls if it really is beneficiary.

>>   * 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.

I was thinking about writing a GC in the GRIN language itself (like
with eval/apply). Generating a unique GC for each program could be
quite efficient, I believe. I find expression the full runtime-system
in GRIN to be rather aestheticly pleasing. (:

-- 
Cheers,
  Lemmih