WinHugs progress report

[Neil Mitchell]

> Sounds good (though the loss of interact is a worry).
Yes, interact is an unfortunate casualty. I hope to be able to put it
back at some point, but it will be quite a bit of work, and involves
me understanding more of how hugs works.

> Does the new version work with Win95?
Maybe, I don't know anyone who has Win95, so its a bit hard to test.
If it doesn't, then I should be able to fix it easily enough. I have
avoided API's which aren't explicitly supported on Win95.

> > giving people -/+98 and other super-haskell options is real enough
> > to stop people using it, if they want non-standard haskell. All the
> > others are very minor.
> This is no worse than the old WinHugs, though, isn't it?

It is worse. The old version lets you change things like overlapping
instances etc, the new one doesn't. You can still use :set to make the
alterations. Its intended to add these back, and should be relatively
easy - its just because I stick to standard haskell its not been
necessary.


> > And also when does WinHugs2 integration want to take place?
> 
> How about right now?

Sounds good. Maybe I could send a big zip with all the files for the
WinHugs directory and then send smaller, self-contained patches for
the hugs directory over about a week? I guess people will want to look
at the hugs patches closer, and some of them could do with slight tidy
ups.

With regards to teh documentation at
http://cvs.haskell.org/Hugs/pages/hugsman/windows.html#sect8.2:

> It also stores options in a .ini file.
It stores options in the registry, and has done for a while now,
several years at least.

> In addition, the current implementation uses a compute-intensive polling process to detect certain events, and this can incur a fairly substantial performance penalty. For these reasons, the Hugs for Windows front-end is not recommended for work on large projects.

No polling anymore, which is why interact broke, and one of the
reasons for a speed increase.

Thanks

Neil