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