[Haskell-cafe] More on the random idea

[Andrew Coppin]

Simon Peyton-Jones wrote:
> | It's too large and complicated to use for small things. E.g., if you
> | want to just dash off a little something that needs to evaluate an
> | expression... Well, you can use the GHC API. But this is highly
> | nontrivial. You get the impression it was added later, and the internal
> | structure of GHC is so complex that it makes it hard to write a
> | lightweight interface to it.
>
> It's certainly true that GHC's API was added later.  But there is no real reason why it should not be easy to use.   We'd be keen to support anyone who wanted to help make that happen.  At the moment there's a bit of chicken and egg problem.
>   

Perhaps I was unduly harsh here. Let me phrase it thus:

It seems to me that GHC represents a *huge* amount of development work. 
(I don't know how long you guys have been working on this thing...) On 
one hand, when you want to do something with the Haskell language, the 
idea of loafing off and letting GHC do all the donkey work for you is 
very appealing. On the other hand, the design goals of GHC seem to be to 
produce top-quality compiled code, and to be as user-friendly as 
possible. (These are not goals I'm going to argue with!) It seems making 
the internal workings of GHC as simple as possible is not a big goal 
(although I don't suppose you go out of your way to make it *hard*). GHC 
is designed to be good at being GHC, rather than good at being a 
collection of flexible, reusable Haskell processing libraries.

In my case, all I was actually trying to do was implement GHCi. (It's a 
good first test.) It took me a few hours, but I did in fact eventually 
get it to work. My plan was to make a program that's essentially GHCi, 
but accepts commands remotely via TCP. But by that point I'd decided 
that maybe just invoking GHC.EXE manually might be significantly easier. 
It's certainly nowhere near as easy as JavaScript's eval() function. 
(But then, Haskell isn't JavaScript, so maybe it's not reasonable to 
expect this level of ease. I don't know.)

Mainly what took the time is that thus stuff doesn't appear to be very 
well documented. (Presumably most GHC developers are busy... 
developing... GHC...) I did eventually get my test program to work, and 
the code wasn't especially large or complex. (Although it was entirely 
devoid of error handling.) I'm a little curios as to why the binary was 
several times larger than either GHC or GHCi, but still.

I didn't see any way to access facilities other than 
compilation/evaluation. (E.g., what type does this have, or please 
desugar this.) But then, I didn't look very hard.

Still, it's not like I could have done any better myself, so maybe I 
should just quit whining...