[Hugs-users] Network.CGI missing in Hugs
bringert at cs.chalmers.se
Tue Jan 9 13:18:05 EST 2007
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.
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
> 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 at haskell.org [mailto:hugs-users-
> bounces at haskell.org] On Behalf Of Bjorn Bringert
> Sent: Sunday, January 07, 2007 1:10 PM
> To: Ian Lynagh
> Cc: Ross Paterson; hugs-users at 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
>> in the first place?). I find it very useful to be able to write
>> code in
>> the style shown in
>> Hugs compatibility is also important, though, and undecidable
>> 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.
> Hugs-Users mailing list
> Hugs-Users at haskell.org
> 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
> delete it from your system.
More information about the Hugs-Users