WinHugs for GHCi, prompt feature

Neil Mitchell ndmitchell at gmail.com
Sun Feb 12 17:22:02 EST 2006


> not a good week for such questions, as the Simons have gone on
> holiday, but here are some pointers.
True, I forgot that...

> - check out the emacs mode for haskell, which does a similar thing
>     http://www.iro.umontreal.ca/~monnier/elisp/#haskell-mode

Thanks for the hint, from what I can tell (without having an Emacs
near by), it just searches for   "^\\*?[A-Z][\\._a-zA-Z0-9]*\\(
\\*?[A-Z][\\._a-zA-Z0-9]*\\)*> " to be a prompt, which is hardly
ideal...


> - if you are serious about this (more than just a few buttons for
>     the ghci/hugs commands;-), you might want to go for a tighter
>     integration with the interactive Haskell implementations.

Its amazing what difference a few buttons makes, but yes, I am serious
about turning this into something quite powerful. However, in order to
make it quite powerful I don't think I really do need that much
integration - just ":t" and a few others should be enough.


>     Hugs has (or had?) the Hugs Server API
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/src/server.c?rev=1.6

Looks nice, but I know Hugs plays with setjmp longjmp internally, and
thats one solid reason for wanting to be in a separate process from
Hugs.

>     GHC has the GHC API (which is also used for the Visual Studio plugin)

As far as I was aware, the GHC API is about looking at the code (i.e.
compiling and examining) - while the side I'm interested in is the
execution.

There are some big advantages to just spawning out to existing
processes - the level of difference between Hugs/GHCi becomes much
smaller, the program can just grab the users existing installation of
the interpretter, and I'm not stuck tracking an unstable API. Of
course, for higher levels of integration I need something better, but
I hope this will suffice for a long time.

Thanks

Neil


More information about the Glasgow-haskell-users mailing list