Re: [Hugs-users] graphics
Ross wrote:
On Wed, Dec 27, 2006 at 11:13:43PM +0000, dfeustel@mindspring.com wrote:
I had done an install of hugs98 into /usr/local/lib/hugs but I notice that almost none of the hugs98 packages got copied into /usr... So I set HUGSDIR=path/to/packages/in/my/user/account.
The X11 and HGL packages won't be built if the system you built Hugs on lacks an X11 build environment (check hugs98/packages/X11/X11.buildinfo). (Similarly OpenGL, GLUT, OpenAL, ALUT.) But at least a dozen packages should be built and installed in all cases.
You could set HUGSDIR=.../hugs98/hugsdir but the packages in there should all be installed by make install. Pointing at the top-level source directory gets you the unprocessed source files, which won't work.
I keep getting new "not found" errors for include files pulled in by the soe.hs file.
I presume you mean imports rather that includes. Perhaps you could post some of what happens.
I committed a couple of the sins you mentioned above. I wound up deleting the Hugs98-sept-2006 which I had built and installing the prebuilt OpenBSD package of Hugs98-03.2005. A lot of things started working. I found the hugs98 demos directory and all the graphics programs worked. I think I am starting to get the hang of Hugs98. :-)
Hi, I am new to the Hugs community. I am drawn to hugs due to perl6's success of bootstrapping from hugs. I am coming from the web development side, so the first thing I am thinking doing is of course, doing some cgi stuff with hugs. It seems that Network.CGI is missing from Hugs Sep 2006 release. I wonder if there is any reason? I also find very little on-line tutorial on how to use each of these standard(?) modules. Can someone point me to the right place? Thanks, Steve Lihn ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
Hi Steve,
I am new to the Hugs community. I am drawn to hugs due to perl6's success of bootstrapping from hugs.
I think what you are probably thinking of is GHC, which is what Pugs is written using. Pugs cannot be run under Hugs, it uses some GHC extensions. However, if you are just going to do "normal" haskell development, learning the language etc, Hugs is a fine choice to get started with.
I am coming from the web development side, so the first thing I am thinking doing is of course, doing some cgi stuff with hugs. It seems that Network.CGI is missing from Hugs Sep 2006 release. I wonder if there is any reason?
Windows/Linux? If Windows did you pick WinHugs or MinHugs? My copy of WinHugs has it installed, not sure what other options/packages have it though. Thanks Neil
Neil, My interest is learning Haskell. Not much to do with Pugs at this point. My OS is redhat linux. There is no binary build for it. So I pulled the linux source release. Did a "make" with prefix $HOME/hugs. Then "make install". Runhugs is under $HOME/hugs/bin. I also installed WinHugs. I checked under packages/network/Network. There are only BSD.hs, Socket.hs, URI.hs, but no CGI.hs? In fact, keyword search CGI on *.hs under packages/ yields nothing on both linux and Windows. Steve -----Original Message----- From: Neil Mitchell [mailto:ndmitchell@gmail.com]
I am new to the Hugs community. I am drawn to hugs due to perl6's success of bootstrapping from hugs.
I think what you are probably thinking of is GHC, which is what Pugs is written using. Pugs cannot be run under Hugs, it uses some GHC extensions. However, if you are just going to do "normal" haskell development, learning the language etc, Hugs is a fine choice to get started with.
I am coming from the web development side, so the first thing I am thinking doing is of course, doing some cgi stuff with hugs. It seems that Network.CGI is missing from Hugs Sep 2006 release. I wonder if there is any reason?
Windows/Linux? If Windows did you pick WinHugs or MinHugs? My copy of WinHugs has it installed, not sure what other options/packages have it though. Thanks Neil ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
Hi Steve,
I also installed WinHugs. I checked under packages/network/Network. There are only BSD.hs, Socket.hs, URI.hs, but no CGI.hs? In fact, keyword search CGI on *.hs under packages/ yields nothing on both linux and Windows.
Not sure what has happened... I checked and Network.CGI is in WinHugs May 2006, but not Sep 2006. The solution to this is to install the May 2006 version (http://cvs.haskell.org/Hugs/downloads/2006-05/WinHugs-May2006.exe) then reinstall the Sep 2006 edition over the top of it, in the same directory. As to why Network.CGI is no longer available, I have absolutely no idea. Since it seems to have disappeared on both Hugs and WinHugs it doesn't sound like its my fault. I can only guess either it got removed from the library (bad) or got dropped from some install file so is missing from Hugs (not great, but easily fixable). I guess only Ross will know about this one. Thanks Neil
Am Samstag, 30. Dezember 2006 13:26 schrieb Neil Mitchell:
Hi Steve,
I also installed WinHugs. I checked under packages/network/Network. There are only BSD.hs, Socket.hs, URI.hs, but no CGI.hs? In fact, keyword search CGI on *.hs under packages/ yields nothing on both linux and Windows.
Not sure what has happened... [...]
The answer is here:
Mon Aug 14 02:56:52 PDT 2006 bringert@cs.chalmers.se * Removed Network.CGI from the network package. A backwards-compatible new Network.CGI is available in the cgi package.
R ./Network/CGI.hs M ./network.cabal -2 +2 M ./package.conf.in -1 _______________________________________________ Cvs-libraries mailing list Cvs-libraries@haskell.org http://www.haskell.org/mailman/listinfo/cvs-libraries
So we probably have to hook the cgi package into Hugs' build system, at least the toplevel Makefile has to be modified (LIBRARIESDIRS) plus the list of packages at the end of convert_libraries. Not sure if this is enough... Hmmm, this redundancy is a bit ugly. Cheers, S.
On Sat, Dec 30, 2006 at 01:37:32PM +0100, Sven Panne wrote:
So we probably have to hook the cgi package into Hugs' build system, at least the toplevel Makefile has to be modified (LIBRARIESDIRS) plus the list of packages at the end of convert_libraries. Not sure if this is enough...
Not possible, unfortunately: the cgi package won't work with Hugs because Hugs lacks one of the functions it uses.
Hi, I am trying to compile htoolkit's HSQL package. Got the following error on my first step. It seems like an internal error from the standard library. Any idea? cd HSQL/HSQL runhugs Setup.lhs configure runhugs: Error occurred ERROR "/home/econ/hugs/lib/hugs/packages/base/Text/ParserCombinators/ReadP.hs" :156 - Syntax error in type expression (unexpected `.') Steve ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
On Wed, Jan 03, 2007 at 04:53:49PM -0500, Lihn, Steve wrote:
I am trying to compile htoolkit's HSQL package. Got the following error on my first step. It seems like an internal error from the standard library. Any idea?
cd HSQL/HSQL runhugs Setup.lhs configure runhugs: Error occurred ERROR "/home/econ/hugs/lib/hugs/packages/base/Text/ParserCombinators/ReadP.hs" :156 - Syntax error in type expression (unexpected `.')
Give runhugs a -98 argument: runhugs -98 Setup.lhs configure
Not possible, unfortunately: the cgi package won't work with Hugs because Hugs lacks one of the functions it uses.
This sounds pretty bad. Couldn't even do some CGI programming with Hugs... How much does it take to make the cgi package compatible with Hugs? Steve ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
Am Mittwoch, 3. Januar 2007 22:59 schrieb Lihn, Steve:
Not possible, unfortunately: the cgi package won't work with Hugs because Hugs lacks one of the functions it uses.
This sounds pretty bad. Couldn't even do some CGI programming with Hugs... How much does it take to make the cgi package compatible with Hugs?
I've tested the new cgi package a few days ago and IIRC there were basically two problems: * Hugs doesn't support System.Environment.getEnvironment yet, but I guess that this could easily be fixed. * Some instances in Network.CGI.Monad overlap, which is not supported in Hugs. I don't know if the overlap is crucial and what the rationale behind this is. Perhaps I've missed some discussions on the libraries list. Perhaps we can simply #ifdef/remove the overlap. Ross? Cheers, S.
On Fri, Jan 05, 2007 at 03:51:31PM +0100, Sven Panne wrote:
I've tested the new cgi package a few days ago and IIRC there were basically two problems:
* Hugs doesn't support System.Environment.getEnvironment yet, but I guess that this could easily be fixed.
Indeed.
* Some instances in Network.CGI.Monad overlap, which is not supported in Hugs. I don't know if the overlap is crucial and what the rationale behind this is. Perhaps I've missed some discussions on the libraries list. Perhaps we can simply #ifdef/remove the overlap. Ross?
One could expand MonadTrans in instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m) replacing it with instance (MonadCGI m) => MonadCGI (ListT m) instance (MonadCGI m) => MonadCGI (ContT m) instance (Error e, MonadCGI m) => MonadCGI (ErrorT e m) instance (MonadCGI m) => MonadCGI (ReaderT r m) instance (MonadCGI m) => MonadCGI (StateT s m) instance (Monoid w, MonadCGI m) => MonadCGI (StateT w m) instance (Monoid w, MonadCGI m) => MonadCGI (RWST r w s m)
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
On Fri, Jan 05, 2007 at 03:51:31PM +0100, Sven Panne wrote:
I've tested the new cgi package a few days ago and IIRC there were basically two problems:
* Hugs doesn't support System.Environment.getEnvironment yet, but I guess that this could easily be fixed.
Indeed.
* Some instances in Network.CGI.Monad overlap, which is not supported in Hugs. I don't know if the overlap is crucial and what the rationale behind this is. Perhaps I've missed some discussions on the libraries list. Perhaps we can simply #ifdef/remove the overlap. Ross?
One could expand MonadTrans in
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
replacing it with
instance (MonadCGI m) => MonadCGI (ListT m) instance (MonadCGI m) => MonadCGI (ContT m) instance (Error e, MonadCGI m) => MonadCGI (ErrorT e m) instance (MonadCGI m) => MonadCGI (ReaderT r m) instance (MonadCGI m) => MonadCGI (StateT s m) instance (Monoid w, MonadCGI m) => MonadCGI (StateT w m) instance (Monoid w, MonadCGI m) => MonadCGI (RWST r w s m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of), but if that's what's needed to get it working with Hugs, I'm ok with it. /Bjorn
Am Freitag, 5. Januar 2007 18:14 schrieb Bjorn Bringert:
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of), but if that's what's needed to get it working with Hugs, I'm ok with it.
Effectively removing Network.CGI from the Hugs community will probably break more programs, so I'll vote for non-overlapping instances, too. Cheers, S.
On Fri, Jan 05, 2007 at 06:14:31PM +0100, Bjorn Bringert wrote:
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of),
Some of my code needs it too (I think I might have requested it be added in the first place?). I find it very useful to be able to write code in the style shown in http://www.haskell.org/pipermail/haskell-cafe/2007-January/021085.html Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'. It feels like a bit of a sledgehammer, but maybe the instance should be put in its own package cgi-undecidable or something? Thanks Ian
On Jan 7, 2007, at 19:03 , Ian Lynagh wrote:
On Fri, Jan 05, 2007 at 06:14:31PM +0100, Bjorn Bringert wrote:
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of),
Some of my code needs it too (I think I might have requested it be added in the first place?). I find it very useful to be able to write code in the style shown in http://www.haskell.org/pipermail/haskell-cafe/2007-January/021085.html
Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'.
It feels like a bit of a sledgehammer, but maybe the instance should be put in its own package cgi-undecidable or something?
Yes, you were the one who requested it in the first place. It was initially in a separate module. As far as I recall, I only moved it to Network.CGI.Monad to avoid it being an orphan instance. This isn't really important I guess. I would be ok with moving it somewhere else. A separate package would probably be the cleanest, since it would allow applications to declare that they need it. /Björn
On Jan 7, 2007, at 19:10 , Bjorn Bringert wrote:
On Jan 7, 2007, at 19:03 , Ian Lynagh wrote:
On Fri, Jan 05, 2007 at 06:14:31PM +0100, Bjorn Bringert wrote:
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of),
Some of my code needs it too (I think I might have requested it be added in the first place?). I find it very useful to be able to write code in the style shown in http://www.haskell.org/pipermail/haskell-cafe/2007-January/ 021085.html
Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'.
It feels like a bit of a sledgehammer, but maybe the instance should be put in its own package cgi-undecidable or something?
Yes, you were the one who requested it in the first place. It was initially in a separate module. As far as I recall, I only moved it to Network.CGI.Monad to avoid it being an orphan instance. This isn't really important I guess. I would be ok with moving it somewhere else. A separate package would probably be the cleanest, since it would allow applications to declare that they need it.
Done. Thanks for the suggestion Ian! The undecidable instance is now in a separate package, available from here: http://darcs.haskell.org/packages/cgi-undecidable/ The cgi package still does not work under Hugs due to the missing getEnvironment. I think that it really needs to use getEnvironment, and not getEnv as the old Network.CGI did. I would like all environment variables to be available, not just the standard ones. The is needed for request-specific variables like HTTP_* and for server-specific ones like REQUEST_URI (set by mod_rewrite). It's not ok to force the user to call getEnv for those either, since the program might be running under FastCGI where the variables do not come from the program environment variables. /Björn
I did not realize reporting a missing CGI module could cause such a lengthy discussion. Since I am new to Haskell, can someone explain why a CGI module, which seems to be a basic for any modern programming language, is such a headache in Haskell? I roughly know it is related to Monad, a state machine. But why is it so difficult to get something from the environment and process the information accordingly? Programs read from environments, databases, files all the time. Do they all have similar issues in Haskell? Steve Lihn -----Original Message----- From: hugs-users-bounces@haskell.org [mailto:hugs-users-bounces@haskell.org] On Behalf Of Bjorn Bringert Sent: Sunday, January 07, 2007 1:10 PM To: Ian Lynagh Cc: Ross Paterson; hugs-users@haskell.org Subject: Re: [Hugs-users] Network.CGI missing in Hugs On Jan 7, 2007, at 19:03 , Ian Lynagh wrote:
On Fri, Jan 05, 2007 at 06:14:31PM +0100, Bjorn Bringert wrote:
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of),
Some of my code needs it too (I think I might have requested it be added in the first place?). I find it very useful to be able to write code in the style shown in http://www.haskell.org/pipermail/haskell-cafe/2007-January/021085.html
Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'.
It feels like a bit of a sledgehammer, but maybe the instance should be put in its own package cgi-undecidable or something?
Yes, you were the one who requested it in the first place. It was initially in a separate module. As far as I recall, I only moved it to Network.CGI.Monad to avoid it being an orphan instance. This isn't really important I guess. I would be ok with moving it somewhere else. A separate package would probably be the cleanest, since it would allow applications to declare that they need it. /Björn_______________________________________________ Hugs-Users mailing list Hugs-Users@haskell.org http://www.haskell.org/mailman/listinfo/hugs-users ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
I wouldn't say that it's a headache, and this was by no means a lengthy discussion, though most of it should maybe have taken place on the libraries or hugs-bugs mailing list. The CGI module already exists, so it's not a problem of whether it is possible to write one in Haskell. The issues had to do with rather fine points of its design, and the compatibility of the current version with Hugs. I think that you would find similar discussions around pretty much any serious library for any programming language. There were two basic issues discussed: - The existing module used undecidable instances, a Haskell extension which is supported by GHC but not by Hugs. This was not essential for the CGI module, but it makes it more easy to use with certain advanced abstractions. The result of the discussion was that the part that was not compatible with Hugs was moved to a separate package, so as to allow the rest of the library to be used in Hugs. - The CGI module uses the getEnvironment function, which gets a a list of all environment variables and their values. This function is unfortunately not available in Hugs yet, but it should be easy to add. An old CGI module, which used to come with Hugs, used the getEnv function instead. This function gets the value of a single named environment variable. The core CGI functionality can be implemented using just getEnv, but when I wrote the new module, I wanted to allow access to all environment variables. There is also the issue that the CGI module is not just for use with the CGI interface. Haskell programs which use the CGI module can be ported to run as FastCGI programs by changing an import and one single function call. This further constrains how we can handle environment variables, but makes the CGI module more useful. Again, this discussion is probably not interesting for most users, but it's the kind of thing that goes on on developers' mailing lists for all software projects. /Björn On Jan 9, 2007, at 18:56 , Lihn, Steve wrote:
I did not realize reporting a missing CGI module could cause such a lengthy discussion. Since I am new to Haskell, can someone explain why a CGI module, which seems to be a basic for any modern programming language, is such a headache in Haskell?
I roughly know it is related to Monad, a state machine. But why is it so difficult to get something from the environment and process the information accordingly? Programs read from environments, databases, files all the time. Do they all have similar issues in Haskell?
Steve Lihn
-----Original Message----- From: hugs-users-bounces@haskell.org [mailto:hugs-users- bounces@haskell.org] On Behalf Of Bjorn Bringert Sent: Sunday, January 07, 2007 1:10 PM To: Ian Lynagh Cc: Ross Paterson; hugs-users@haskell.org Subject: Re: [Hugs-users] Network.CGI missing in Hugs
On Jan 7, 2007, at 19:03 , Ian Lynagh wrote:
On Fri, Jan 05, 2007 at 06:14:31PM +0100, Bjorn Bringert wrote:
On Jan 5, 2007, at 18:04 , Ross Paterson wrote:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m)
I added that instance reluctantly, but it is quite useful when you write your own monad transformers and want to wrap CGIT. Removing it would break some existing code (Hope is the only one I know of),
Some of my code needs it too (I think I might have requested it be added in the first place?). I find it very useful to be able to write code in the style shown in http://www.haskell.org/pipermail/haskell-cafe/2007-January/ 021085.html
Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'.
It feels like a bit of a sledgehammer, but maybe the instance should be put in its own package cgi-undecidable or something?
Yes, you were the one who requested it in the first place. It was initially in a separate module. As far as I recall, I only moved it to Network.CGI.Monad to avoid it being an orphan instance. This isn't really important I guess. I would be ok with moving it somewhere else. A separate package would probably be the cleanest, since it would allow applications to declare that they need it.
/Björn_______________________________________________ Hugs-Users mailing list Hugs-Users@haskell.org http://www.haskell.org/mailman/listinfo/hugs-users
---------------------------------------------------------------------- -------- Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system.
---------------------------------------------------------------------- --------
- The existing module used undecidable instances, a Haskell extension which is supported by GHC but not by Hugs.
?? as far as i recall, Hugs was the first Haskell implementation to bite the bullet and accept undecidable instances as a design option (although its predecessor apparently also had the undecidability feature). http://cvs.haskell.org/Hugs/pages/users_guide/class-extensions.html are you thinking of interactions with other extensions, perhaps? claus
On Jan 9, 2007, at 22:35 , Claus Reinke wrote:
- The existing module used undecidable instances, a Haskell extension which is supported by GHC but not by Hugs.
??
as far as i recall, Hugs was the first Haskell implementation to bite the bullet and accept undecidable instances as a design option (although its predecessor apparently also had the undecidability feature).
http://cvs.haskell.org/Hugs/pages/users_guide/class-extensions.html
are you thinking of interactions with other extensions, perhaps?
Sorry, my bad, that was confused. Some earlier comments from this thread to add to the confusion: Sven Panne wrote:
Effectively removing Network.CGI from the Hugs community will probably break more programs, so I'll vote for non-overlapping instances, too.
Ian Lynagh wrote:
Hugs compatibility is also important, though, and undecidable instances are marked "probably no" for Haskell'.
The bottom line is that the instance: instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m) where needs both overlapping and undecidable instances, doesn't work in Hugs, and probably won't be Haskell'-compatible. However, the problem should be solved now, since that instance is no longer in the cgi package. /Bjorn
Ian Lynagh wrote:
undecidable instances are marked "probably no" for Haskell'.
which, btw, I think is a bad idea. I had really hoped that Haskell' would sort out the differences and standardize the behaviour of such common extensions. not standardizing them won't make them go away, nor will they suddenly cease to be useful. they will just keep causing problems because implementations interpret them differently.. but I lost that argument long ago.
The bottom line is that the instance:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m) where
needs both overlapping and undecidable instances, doesn't work in Hugs, and probably won't be Haskell'-compatible.
but overlapping instances were also pioneered in Hugs!-) there are differences, eg, in how FDs combine with overlaps, or how scoped type variables in instances are interpreted, but Hugs has both unlimited and overlapping instances. so the problem has to lie elsewhere.. claus
On Wed, Jan 10, 2007 at 09:47:04PM -0000, Claus Reinke wrote:
Bjorn Bringert wrote:
The bottom line is that the instance:
instance (MonadTrans t, MonadCGI m, Monad (t m)) => MonadCGI (t m) where
needs both overlapping and undecidable instances, doesn't work in Hugs, and probably won't be Haskell'-compatible.
but overlapping instances were also pioneered in Hugs!-)
there are differences, eg, in how FDs combine with overlaps, or how scoped type variables in instances are interpreted, but Hugs has both unlimited and overlapping instances.
Yes, Hugs accepts this one with +o. Hugs does have additional restrictions on overlapping instances that GHC defers to their point of use, but this particular case is OK, because one of the overlapping instances is a substitution instance of the other.
participants (8)
-
Bjorn Bringert -
Claus Reinke -
dfeustel＠mindspring.com -
Ian Lynagh -
Lihn, Steve -
Neil Mitchell -
Ross Paterson -
Sven Panne