[Hugs-users] Fwd: Hugs'06

[Bulat Ziganshin]

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 at HotPOP.com