my first letter :)
first, bugs. i attached two programs, which make problems under
WinHugs/Feb04. The first shows error in `poke` for Word64
values, and second even don't compiles because of problems in
de-sugaring parallel comprehensions
second, my greatest gratitudes for such great program, to all
the Hugs team. I write program which working version is compiled with
GHC, but GHC (and even GHCi) is somewhat slow and unfriendly
environment. Hugs greatest compliance with GHC make developing my
program much faster, and its WinHugs environment are much more
user-friendly than ghci. but after several months of developing base
part of my program with Hugs+GHC i have to switch to GHC only and
below is a list of incompatibilities/inconveniencies which cause this.
If you can fix at least some of them in next Hugs release, i will
be very glad
1) lack of preprocessor in WinHugs. i know that i can setup makefile
to do this, but this is not convenient. preprocessor is absolutely
needed for me to mask differences between GHC and Hugs
2) lack of hGetBuf/hPutBuf operations
3) monomorphism restriction
4) inability to create <
first, bugs. i attached two programs, which make problems under WinHugs/Feb04. Thats really old! Unfortunately, it is the most recent official WinHugs release, however a new beta version of WinHugs is at http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php - you may have more success with this build.
The first shows error in `poke` for Word64 values, and second even don't compiles because of problems in de-sugaring parallel comprehensions Have you switched on Haskell 98 extensions? Parallel comperhensions are not standard Haskell 98, but I think they are supported with extensions on.
WinHugs environment are much more user-friendly than ghci. Hopefully the new version of WinHugs will be significantly more user friendly than even the old version of WinHugs, that has been my experience using it.
1) lack of preprocessor in WinHugs. i know that i can setup makefile to do this, but this is not convenient. preprocessor is absolutely needed for me to mask differences between GHC and Hugs The Linux build and console versions of Hugs have these. Unfortunately WinHugs does not :( I did write a version which roughly hacked in a preprocessor, but then I went and modified my code so it didn't require a preprocessor, and the changes were very hacky, so I never took the time to get them submitted. Why are you using a preprocessor? If you give me your situation, show its 100% essential, and its the one thing holding you back that would probably motivate me enough to get the changes in finally.
several more complaints about WinHugs environment: The old WinHugs, the new WinHugs has quite a few of these fixed.
1) mouse-clicking on the scroll bar at the right must, at Windows standards, scroll whole page up/down, but WinHugs scrolls only one line at a time :(
Fixed! This used to really annoy me too, and was the main reason I started hacking at WinHugs.
2) easy-to-open window with list of commands previously executed, with ability to reexecute them or just put to cmdline, will be very helpful. if i issue many different commands, it is more useful, than scrolling through them with Up/Down keys
Thats certainly a possibility, not that much work, and I quite lack that idea. I'll think about it.
3) calling editor, when error encountered, with positioning it on the line with error Done! This is a really useful feature.
4) F1 (Help) command loads hugs.hlp while my win xp can show more user-friendly hugs98.chm Done, I killed off hugs.hlp entirely I think - it was outdated and I couldn't figure how to build it.
If you have any more suggestions relating to the new build of WinHugs, I'd be delighted to hear them. Thanks Neil
Hello Neil, Friday, December 09, 2005, 7:25:51 PM, you wrote:
values, and second even don't compiles because of problems in de-sugaring parallel comprehensions NM> Have you switched on Haskell 98 extensions?
of course NM> Hopefully the new version of WinHugs will be significantly more user NM> friendly than even the old version of WinHugs, that has been my NM> experience using it. i will look at it
1) lack of preprocessor in WinHugs. i know that i can setup makefile to do this, but this is not convenient. preprocessor is absolutely needed for me to mask differences between GHC and Hugs NM> The Linux build and console versions of Hugs have these. Unfortunately NM> WinHugs does not :( I did write a version which roughly hacked in a NM> preprocessor, but then I went and modified my code so it didn't NM> require a preprocessor, and the changes were very hacky, so I never NM> took the time to get them submitted. Why are you using a preprocessor? NM> If you give me your situation, show its 100% essential, and its the NM> one thing holding you back that would probably motivate me enough to NM> get the changes in finally.
GHC has a lot of features, which i need: hGetBuf/hPutBuf, Ctrl-Break handling, forkOS, getProgArgv, FastMutInt library, parallel arrays. so i want to isolate use of GHC-specific features in #ifdefs. also my program contains windows-specific and even x86-specific Haskell code (it is unaligned memory acces used to make things go faster). so my program have many conditional compilation and i think it is typical for any real-world multi-platform program. imho preprocessing will be useful not only for me, but for anyone who need to develop large program which eventually will be compiled by another Haskell implementation. as i already sayed, highest level of compatibility between ghc and hugs make such scenario (developing with hugs and compiling final version with ghc) perfectly possible. and counting the fact that hugs load programs 10 times faster than ghci, the choice is obvious and about implementing preprocessing: can't you just read from pipe "cpp src.hs" instead of reading from "src.hs"? or may be it will be more convenient to include preprocessing library directly in your sources? -- Best regards, Bulat mailto:bulatz@HotPOP.com
Hello Neil, Friday, December 09, 2005, 7:25:51 PM, you wrote: btw, i don't received copy of your letter in maillist (my mailer don't skip such duplicate letters) NM> If you have any more suggestions relating to the new build of WinHugs, NM> I'd be delighted to hear them. i downloaded mini-version. automatic Vim integration is amazing! i want to repeat command and press white Up key. it just moves cursor around screen :( then i tried to use Grey Up and found that it recalls last command issued. but when i load my "main.hs" module VIA MENU and then use Up key to recall this command, then command recalled contains "\n" char (cursor moves to the next line) and when WinHugs trying to execute such command, it just traps there is no Foreign libraries. it is intended for mini-version? for me, it will be ideal if WinHugs distro don't contain OpenGL and Win32 libs, but includes all other libs (that was in WinHugs2003) and runhugs to run Haskell scripts. also you can reduce size of large distro by 1.5-2 times by using installation engine which suports CAB or LZMA compression (Nullsoft installer, for example) -- Best regards, Bulat mailto:bulatz@HotPOP.com
Hello Bulat, Sunday, December 11, 2005, 1:53:03 AM, you wrote: BZ> runhugs to run Haskell scripts. also you can reduce size of large BZ> distro by 1.5-2 times by using installation engine which suports CAB BZ> or LZMA compression (Nullsoft installer, for example) to justify: WinHugs 2003, which is 30 mb uncompressed, and has 8.4 mb installation, takes only 3.2 mb when compressed in CAB, and 2.6 mb when compressed in LZMA -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Fri, Dec 09, 2005 at 10:18:10AM +0300, Bulat Ziganshin wrote:
first, bugs. i attached two programs, which make problems under WinHugs/Feb04. The first shows error in `poke` for Word64 values, and second even don't compiles because of problems in de-sugaring parallel comprehensions
Thanks for these reports. The first one is now fixed in CVS. For the second, you need to import the Haskell 98 module List to get zip4. The CVS version now looks in both Data.List and List.
2) lack of hGetBuf/hPutBuf operations
These are present in more recent versions of Hugs.
3) monomorphism restriction
A known bug, but unlikely to be fixed soon. You can work around it with explicit signatures. Sorry.
4) inability to create <
> functions, so i can call back from C to Haskell. but i think that this is huge task and i personally can debug most parts of my programs without it while writing the last sentence, i scanned Hugs docs directory for FFI word and found that import wrappers are supported, but how it works is not documented. can i request a section on using FFI in Hugs docs? i can even write small part of it, describing compilation of foreign imports in windows Hugs
foreign import wrapper is documented in the FFI spec. The Hugs User's Guide has a section "Compiling modules that use the Foreign Function Interface" that explains how to prepare FFI modules for use with Hugs.
Hello Ross, one more feature i want to request is ghc-like extended pattern guards: f x | [y] <- x = 0 -- Best regards, Bulat mailto:bulatz@HotPOP.com
Am Freitag, 9. Dezember 2005 08:18 schrieb Bulat Ziganshin:
[...] 1) lack of preprocessor in WinHugs. i know that i can setup makefile to do this, but this is not convenient. preprocessor is absolutely needed for me to mask differences between GHC and Hugs
At least on *nices Hugs comes with cpphs (disguised as cpphs-hugs), but I'm not sure about Hugs on WinDoze here. And instead of Makefiles, Cabal might be a better option nowadays.
2) lack of hGetBuf/hPutBuf operations [..] 4) inability to create <
> functions, so i can call back from C to Haskell. but i think that this is huge task and i personally can debug most parts of my programs without it [...]
Both are needed for my various Haskell bindings for OpenGL/GLUT/OpenAL/ALUT, so you can be sure that they work on Hugs... ;-) I think that a new official Hugs release is really overdue and I'm not sure about the reasons for not doing this. Ross? One question might be what to do about the various packages, but I would vote for the "sumo approach" and ship as much as we can together with Hugs. When the release after that will be done, there is probably already enough Cabal/Hackage/etc. out there that we can go for a more modular release approach. Another question is: Who will be the packager for the various platforms? As usual, I can provide RPMs for x86 SuSE distros. Cheers, S.
On Sat, Dec 10, 2005 at 01:15:06PM +0100, Sven Panne wrote:
I think that a new official Hugs release is really overdue and I'm not sure about the reasons for not doing this.
Waiting on Windows, as usual. But there's been progress there; it builds, and Neil has made available a test version of WinHugs at http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php
One question might be what to do about the various packages, but I would vote for the "sumo approach" and ship as much as we can together with Hugs. When the release after that will be done, there is probably already enough Cabal/Hackage/etc. out there that we can go for a more modular release approach.
I think we can go for the modular approach now as far as source bundles are concerned: one source bundle with the interpreter plus cpphs, hsc2hs and the base, haskell98, Cabal and haskell-src packages, with each of the other library packages in their own Cabal bundle. (Splitting off haskell-src awaits improvements to Cabal's treatment of preprocessors.) Binary packagers could amalgamate them if they wished. So there could be an omnibus binary package for Windows, though there might be demand for a smaller one as well.
Another question is: Who will be the packager for the various platforms? As usual, I can provide RPMs for x86 SuSE distros.
We're usually left packaging to others, except for your RPMs and Windows. Neil has his own installer for Windows.
participants (4)
-
Bulat Ziganshin -
Neil Mitchell -
Ross Paterson -
Sven Panne