Fwd: Hugs'06

[Bulat Ziganshin]

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 <<foreign import "wrapper">> 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

several more complaints about WinHugs environment:

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 :(

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

3) calling editor, when error encountered, with positioning it on the
line with error

4) F1 (Help) command loads hugs.hlp while my win xp can show more
user-friendly hugs98.chm



--
Best regards,
 Bulat                            mailto:[hidden email]
_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Neil Mitchell]

> 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
_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Ross Paterson]

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 <<foreign import "wrapper">> 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.

_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[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:[hidden email]



_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Sven Panne]

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 <<foreign import "wrapper">> 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.
_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Bulat Ziganshin]

Hello Ross,

one more feature i want to request is ghc-like extended pattern guards:

f x | [y] <- x = 0


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Bulat Ziganshin]

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:[hidden email]



_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Bulat Ziganshin]

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:[hidden email]



_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users

[Ross Paterson]

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.

_______________________________________________
Hugs-Users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hugs-users