headers
oleg | 1 Jun 2005 08:07
Picon
Favicon

Simulating OO programming with type classes; writing a factory fu nction


Alistair Bayley wrote:

> There's a small problem: how to write a factory function that returns values
> of various subtypes. The makeSubType function below won't compile, obviously
> because the returns types are different (they're not the same 'm').

Indeed, expressions in both branches of an `if' statement

>   if s == "SubBase1"
>   then SubBase1 3
>   else SubBase2 (SubBase1 4)

must be of the same type. If we had intersection types (I'm not
complaining!), the compiler would have derived the intersection by
itself. As things are now, we have to make the intersection manually:
we have to abstract away irrelevant pieces. Expressions
`SubBase1 3' and `SubBase2 (SubBase1 4)' have in common the fact that
both have types that are instances of a Method class. So, we have to
write that common piece of information explicitly. There are two ways
of doing this, which can be called direct style and CPS style. In
direct style, we do

> data WM = forall m. Method m => WM m
> makeSubType1 :: String -> WM 
> makeSubType1 s =
>   if s == "SubBase1"
>   then WM $ SubBase1 3
>   else WM $ SubBase2 (SubBase1 4)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcin 'Qrczak' Kowalczyk | 1 Jun 2005 14:23
X-Face
Picon

Re: Space questions about intern and sets

Gracjan Polak <gracjan <at> acchsh.com> writes:

> intern :: Ord a => a -> a
> intern x = unsafePerformIO $ internIO x
>
> iorefset :: Ord a => IORef(Map.Map a a)
> iorefset = unsafePerformIO $ do
>      newIORef $ Map.empty

It will not work because you can't put values of different types as
keys of the same dictionary, as you can't compare them.

--

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak <at> knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
Permalink | Reply | 9 comments |
headers
Thomas Davie | 1 Jun 2005 16:51
Picon
Gravatar

Type extensions

Hi,
   I was wondering if I hat missed something and it was possible to  
do this within the Haskell type system or not...

Essentially I would like some sort of inderritance property for  
Haskell types, I often find myself wanting to for example extend a  
tree with black/white colouring, or later extend the tree with some  
sort of ID, etc.

So I would eno up with three data types

data MyTree = Branch MyTree MyTree | Leaf

type BwTag = Bool
data MyBwTree = Branch BwTag MyBwTree MyBwTree | Node BwTag

data MyBwTaggedTree = Branch BwTag Int MyBwTaggedTree MyBwTaggedTree  
| Node BwTag Int

and several functions to move from one to another.  (Or define the  
most complex and not always use all the attrdbutes). What I would  
prefer is to be able to spocify something like:

data MyTree = Branch MyTree MyTree | Leaf

type BwTag = Bool
data MyBwTree extends MyTree with BwTag=True

data MyBwTaggedTree extends MyBwTree with Int=0
(Continue reading)

Permalink | Reply | 4 comments |
headers
Henning Thielemann | 1 Jun 2005 16:54
Picon

Re: Type extensions


On Wed, 1 Jun 2005, Thomas Davie wrote:

> Hi,
>    I was wondering if I hat missed something and it was possible to
> do this within the Haskell type system or not...
>
> Essentially I would like some sort of inderritance property for
> Haskell types, I often find myself wanting to for example extend a
> tree with black/white colouring, or later extend the tree with some
> sort of ID, etc.
>
> So I would eno up with three data types
>
> data MyTree = Branch MyTree MyTree | Leaf
>
> type BwTag = Bool
> data MyBwTree = Branch BwTag MyBwTree MyBwTree | Node BwTag

What about

data MyTree a = Branch a (MyTree a) (MyTree a) | Node a

and the types
 MyTree ()
 MyTree Bool
 MyTree (Bool, Int)
 ?
Permalink | Reply | 2 comments |
headers
Thomas Davie | 1 Jun 2005 17:03
Picon
Gravatar

Re: Type extensions


On 1 Jun 2005, at 15:54, Henning Thielemann wrote:

>
> On Wed, 1 Jun 2005, Thomas Davie wrote:
>
>
>> Hi,
>>    I was wondering if I hat missed something and it was possible to
>> do this within the Haskell type system or not...
>>
>> Essentially I would like some sort of inderritance property for
>> Haskell types, I often find myself wanting to for example extend a
>> tree with black/white colouring, or later extend the tree with some
>> sort of ID, etc.
>>
>> So I would eno up with three data types
>>
>> data MyTree = Branch MyTree MyTree | Leaf
>>
>> type BwTag = Bool
>> data MyBwTree = Branch BwTag MyBwTree MyBwTree | Node BwTag
>>
>
> What about
>
> data MyTree a = Branch a (MyTree a) (MyTree a) | Node a
>
> and the types
>  MyTree ()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henning Thielemann | 1 Jun 2005 17:12
Picon

Re: Type extensions


On Wed, 1 Jun 2005, Thomas Davie wrote:

> On 1 Jun 2005, at 15:54, Henning Thielemann wrote:
>
> > What about
> >
> > data MyTree a = Branch a (MyTree a) (MyTree a) | Node a
> >
> > and the types
> >  MyTree ()
> >  MyTree Bool
> >  MyTree (Bool, Int)
> >  ?
>
> That's exactly what I would normally do, but my data type is in a
> library and is not parameterised.

Then it is the wrong library. :-)
Permalink | Reply | 0 comments |
headers
John Goerzen | 1 Jun 2005 17:18
Favicon

Wash broken with GHC 6.4

Hi,

I'm trying to use Wash with GHC 6.4.  I have applied the patch from
http://article.gmane.org/gmane.comp.lang.haskell.libraries/3160, and now
it at least compiles.  However, despite using -package WASH -package
WASH-CGI -package WASHHTML, ghc is not automatically sending the
input files through wash2hs.  GHC 6.2 did this.

Incidentally, is Wash dead upstream?  I am surprised that there is no
upstream version yet that even tries to work with GHC 6.4.

-- John
Permalink | Reply | 0 comments |
headers
John Goerzen | 1 Jun 2005 19:44
Favicon

CGI module almost useless

My apologies if this sounds like a bit of a rant; I know people put good
effort into this, but....

The Network.CGI module in fptools (and GHC) is not very useful.  I think
that it should be removed or re-tooled.  Here are the main problems with
it:

1. It does not permit custom generation of output headers.  Thus the CGI
script cannot do things like set cookies, manage HTTP auth, etc.

2. It does not permit generation of anything other than text/html
documents.  Many CGI scripts are used to manage other types of
documents.  Notably this makes it incompatible with serving up even
basic things like stylesheets and JPEGs.

3. It does not permit the use of any custom design to serve up HTML,
forcing *everything* to go through Text.Html.  This makes it impossible
to do things like serving up HTML files from disk.

4. There is documentation in the code, but it is as comments only, and
doesn't show up in the Haddock-generated GHC library reference.  (Should
be an easy fix)

5. It does not appear to support file uploads in any sane fashion

Is there a better CGI module out there somewhere that I'm missing, or
should I just set about writing my own?
Permalink | Reply | 19 comments |
headers
Jeremy Shaw | 1 Jun 2005 19:54

Re: CGI module almost useless

Hello,

I have done all of those things in WASH. But, don't let that stop you
from writing something better :) I think some people started a project
to write a CGI interface based on a 'Category' -- where a 'Category'
is like an 'Arrow' without the 'pure/arr' function...

Jeremy Shaw.

At Wed, 1 Jun 2005 17:44:38 +0000 (UTC),
John Goerzen wrote:
> 
> My apologies if this sounds like a bit of a rant; I know people put good
> effort into this, but....
> 
> The Network.CGI module in fptools (and GHC) is not very useful.  I think
> that it should be removed or re-tooled.  Here are the main problems with
> it:
> 
> 1. It does not permit custom generation of output headers.  Thus the CGI
> script cannot do things like set cookies, manage HTTP auth, etc.
> 
> 2. It does not permit generation of anything other than text/html
> documents.  Many CGI scripts are used to manage other types of
> documents.  Notably this makes it incompatible with serving up even
> basic things like stylesheets and JPEGs.
> 
> 3. It does not permit the use of any custom design to serve up HTML,
> forcing *everything* to go through Text.Html.  This makes it impossible
> to do things like serving up HTML files from disk.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Peter Simons | 1 Jun 2005 20:01
Picon
Gravatar

Re: CGI module almost useless

John Goerzen writes:

 > Is there a better CGI module out there somewhere [...]?

http://cryp.to/formdata/

The module addresses your points insofar as that it doesn't
prohibit you from solving them yourself -- like Network.CGI
does. Patches to improve (read: add) documentation would be
very welcome. ;-)

Peter
Permalink | Reply | 0 comments |

Gmane