Re: Network.CGI missing in Hugs

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: [email protected] [mailto:hugs-users- 
> [email protected]] On Behalf Of Bjorn Bringert
> Sent: Sunday, January 07, 2007 1:10 PM
> To: Ian Lynagh
> Cc: Ross Paterson; [email protected]
> 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
> [email protected]
> 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.
>
> ---------------------------------------------------------------------- 
> --------