On Tue, Jan 27, 2009 at 09:18:55PM +0000, Duncan Coutts wrote:

...

I see Hugs last source code snapshot dates back to 2006. Was there any updates?

Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. It's equivalent in time to ghc-6.6 I think, and a lot of people still use that and that is the base line for compatibility for many projects.

Of course how well it works will depend on just what you're trying to do.

I have tried to maintain Hugs compatibility in all my libraries, but I must admit I am dropping it for many, due to various problems. It is mainly that libraries I use from others haven't even been tried with Hugs or have weird issues: * utf8-string imports an unsafe ByteString module, which doesn't exist in Hugs (its contents are just in regular ByteString). Meant I had to drop Hugs support for HDBC-postgresql. * A big annoyance today: Hugs inexplicably lacks Data.Time.Format entirely. * Its regexp issues have been annoying many times in the past, if memory serves. Things would be a lot better if the libraries would just be maintained. As I have been going through updating my libraries in the past week, I have been wondering myself how much time to put into maintaining Hugs libraries. Hugs still has its place, especially on small ARM devices like the Zaurus or N810 where ghci doesn't run. But it takes a community to make support viable; if the common libraries that everyone uses don't work on Hugs, then people won't use it. The other problem is that Hugs just doesn't support the optional flexibility that GHC does with typeclasses. I had to resort to code generation to generate a ton of instances for Convertible that I could have done in a few lines of code with GHC instead of a few hundred with Hugs. Though this is a rather pathological case for me. Just to close -- I will point out that ghci doesn't work on many platforms that Hugs does (though ghc does). Hugs is the only interpreter on some of these platforms. -- John

On 2009 Jan 28, at 0:15, Benjamin L.Russell wrote:

Although a GUI interface makes little difference to most UNIX/Linux users, for some Haskell beginners in the Windows/OS X world, the availability of a GUI interface could make the experience more appealing, especially at first.

Given that some other functional programming languages provide a GUI interface for Windows/OS X users (PLT Scheme, Erlang, and O'Caml come to mind), if Hugs is likely to continue to have compatibility problems with GHC, then is there any way an interface similar to that already available for WinHugs could be created for GHCi?

I've seen code in the GHC codebase for Gtk+; no idea what state it's in or if it ever worked. But apparently someone has given thought to it at some point. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Tue, 2009-01-27 at 21:41 -0600, John Goerzen wrote:

I have tried to maintain Hugs compatibility in all my libraries, but I must admit I am dropping it for many, due to various problems. It is mainly that libraries I use from others haven't even been tried with Hugs or have weird issues:

[..]

Things would be a lot better if the libraries would just be maintained.

It would be a lot easier if cabal-install worked for hugs then testing would be much simpler for most developers. However at the moment hugs does not provide the installed package information files that cabal-install needs to be able to track installed packages and plan new installations. Cabal does install these files for new packages, but the hugs distribution does not include them for the core packages that it ships. So a new hugs release with more up-to-date libraries and support for cabal-install would make it much easier for everyone else to check their packages with hugs. Also, the default per-user library path that hugs searches is not to everone's liking $HOME/lib/hugs/packages. Unfortunately if cabal does not put things there by default then hugs will not be able to find them. If anyone has suggestions that'd be great. Perhaps we could ask for hugs to read its default search path from ~/.hugs/some-config-file Duncan

On Tuesday 10 February 2009 06:41:54 am Simon Marlow wrote:

John Goerzen wrote:

...

Just to close -- I will point out that ghci doesn't work on many platforms that Hugs does (though ghc does). Hugs is the only interpreter on some of these platforms.

I didn't see anyone follow up to this so I'll just mention that nowadays GHCi works wherever GHC works, since 6.10.1. Actually I think most platforms worked with 6.8.1, but 6.10.1 added libffi which meant that GHCi also gets working FFI support on any platform supported by libffi, which is most of them.

Cheers, Simon

Counterexample: GHC 6.10.1 works on linux/ppc, GHCi 6.10.1 does not. (6.8.3 worked, though.) Regards, -- Conrad Meyer

On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts wrote:

Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version.

I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR "./Distribution/Compat/ReadP.hs":70 - Syntax error in module definition (unexpected selector "#if") The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions?

wren ng thornton wrote:

Bryan O'Sullivan wrote:

...

On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts wrote:

...

Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version.

I've been unable to figure out how to build Cabal with Hugs 2006.09.04:

$ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR "./Distribution/Compat/ReadP.hs":70 - Syntax error in module definition (unexpected selector "#if")

The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions?

That looks like a standard "CPP not enabled" error message. Try passing -F"$cpp" where $cpp is the command for running cpp as a filter. If the FFI is used anywhere, you need to compile with ffihugs before using hugs (see the man page).

That is, -F"cpp -P" should work on most systems. -- Live well, ~wren

On Wed, 2009-01-28 at 12:35 -0800, Bryan O'Sullivan wrote:

On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts wrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version.

I've been unable to figure out how to build Cabal with Hugs 2006.09.04:

$ runhugs -98 Setup configure --hugs --prefix=/usr runhugs: Error occurred ERROR "./Distribution/Compat/ReadP.hs":70 - Syntax error in module definition (unexpected selector "#if")

The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions?

I'm not sure how it was ever supposed to work, that is bootstrapping Cabal directly using runhugs on the Setup.hs script in the Cabal dir. Cabal has always had some cpp in it and (as far as I know) hugs does not have a -cpp flag. I presume the hugs build system has some workaround to cpp all the files first. The way I've tested it recently is to build the Setup.hs with ghc and use that to install Cabal for hugs. From then on one can use runhugs to run other Setup scripts. If you can get the search path right (ie to not look in the current dir) then I expect it would also be possible to bootstrap using a pre-existing Cabal library for hugs. Duncan

On Thu, 2009-01-29 at 20:49 +0000, Ross Paterson wrote:

...

If you can get the search path right (ie to not look in the current dir) then I expect it would also be possible to bootstrap using a pre-existing Cabal library for hugs.

Unfortunately that won't work: runhugs always adds the directory containing the Main module to its search path for modules imported by Main, so that multi-module programs work. This will be a problem for upgrading Cabal (only, I think).

Should be ok, Cabal is always supposed to be built with itself rather than any pre-existing install. Duncan

On Thu, Jan 29, 2009 at 10:21:42PM +0000, Malcolm Wallace wrote:

On 29 Jan 2009, at 20:49, Ross Paterson wrote:

...

Hugs uses cpphs, but it has to build a dozen packages (including Cabal) before cpphs is available. Once it is, they're built again.

That strikes me as odd. The cpphs implementation deliberately has minimal dependencies - Haskell'98 libraries only, and no internal cpp (rather obviously). It should be possible to build cpphs first, before any package.

I realize that nhc98/yhc treat the Haskell 98 modules as primitive, but in the libraries shared by GHC and Hugs, the haskell98 package depends on 7 other packages. It's true that we could then run cpphs directly, but we need Cabal to build hsc2hs and everything else, and it needs 3 more.