On Sat, May 26, 2007 at 07:41:19PM +0100, Andrew Coppin wrote:
Donald Bruce Stewart wrote:
The #haskell people have been working on this for about 3 years now. The result is the 'runplugs' program, which I've talked about in previous mails.
http://www.cse.unsw.edu.au/~dons/code/lambdabot/scripts/RunPlugs.hs
It uses hs-plugins for the evaluation, along with the points about IO prevention via type checking, resource limits controlled by the OS, language extension preventions, and a trusted (audited) module base.
The security mechanisms were briefly described in the 2004 hs-plugins paper, if I recall, but otherwise, I don't think we've documented the techniques. Maybe we should, as many issues have been encountered over the years, further and further constraining the kinds of things that are allowed.
For me, the unfortunate thing is that there seems to be no interpreter for Haskell written in Haskell. (Except for GHC, which is *huge*.) We
Actually, there exists no interpreter for Haskell. Period.
have a Haskell parser [which is complex beyond usability], but no interpreter. It would be nice if one existed, and I'm trying to implement one... but on the other hand, one doesn't want to say to people "hey, come learn Haskell, try this web interpreter" and then have them find it doesn't implement Haskell precisely. So it looks like I'm
Haskell has never been implemented. Every implementation has a large collection of corner cases that aren't correctly parsed; these can be recognized as the wontfix bugs.
stuck with present technology - and that essentially means GHC. (Other compilers? What other compilers??)
As far as I know, hs-plugins works by taking an expression, writing it to a file, calling GHC to parse it, transform it to Core, optimise it, transform it to STG, optimise it, transform it to C--, optimise it, transform it to ANSI C, optimise it, pass it to GCC, compile it, link it, and *then* using the GHC runtime linker to load the generated object code into memory, type-check it, and, finally, execute it.
No, the link step is omitted - the runtime loader works directly on .o files. This cuts several seconds off the sequence, making it neglible compared to IRC lag.
OTOH, GHCi just takes an expression, parses it and interprets it. This
Haha, no. GHCi takes an expression, parses it, wraps it in module Main { main = print (expr) }, type checks it, transforms it to Core, optimizes, transforms to STG, optimizes, transforms to object code for a bytecode machine, links it, and emulates the result. Three times, since it needs to try each of expr, expr >>= print, and print expr. Hugs is also a full compiler, but for some dumb reason doesn't support saving the object code to disk, so you have to recompile everything each time.
appears to be a *much* more lightweight approach. I have had some
Not at all. GHCi seems much faster because GHC's nontrivial startup overhead is amortized over the entire run.
success in using the GHC API to write a program that is essentially GHCi - you type stuff in, it executes it. Now, if I could write a complete full-featured HTTP server and feed that into it instead of stdin and stdout, I could make a web server for executing Haskell... But, hmm, that's not going to happen any time soon.
...or, I could use GHC -e as I described earlier. But I have to look at figuring out how to prevent it doing Bad Things. (Lambdabot gives me an idea. Write a module that imports all the stuff you might want interactively, and process the user-supplied script to make sure it doesn't issue any imports, and then you can precisely control what functions the code can call.)
Whatever... I'd just like to see an online way to run Haskell, and since the Lambdabot webpage still shows no sign of working...
That's my fault - I designed a much simpler configuration interface for lambdabot, but nobody has been motivated to un-bitrot GOA yet. Stefan