Fwd: UNPACK Existential datatype

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: UNPACK Existential datatype

Nicholas Clarke
I'd like to be able to use the UNPACK pragma on an existentially quantified datatype. So as in the below example:

{-# LANGUAGE ExistentialQuantification #-}

data Foo = forall a. Show a => Foo !a
instance Show Foo where
  show (Foo a) = "Foo! " ++ show a

data Bar =
    Bar {-# UNPACK #-} !Foo
  deriving (Show)

main :: IO ()
main = do
  let foo = Foo "Hello"
      bar = Bar foo
  print bar

I would expect the `Foo` constructor to be unpacked into Bar, as if I had written:

data Bar = forall a. Show a => Bar !a

However, instead I get the 'Ignoring unusable UNPACK pragma on the first argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a workaround to get it to do so?

Cheers,

Nick



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Roman Cheplyaka-2
Interesting question. I managed to trace this to:

compiler/basicTypes/MkId.hs:699

isUnpackableType fam_envs ty
  | Just (tc, _) <- splitTyConApp_maybe ty
  , Just con <- tyConSingleAlgDataCon_maybe tc
  , isVanillaDataCon con
  = ok_con_args (unitNameSet (getName tc)) con
  | otherwise
  = False

where isVanillaDataCon is defined as:

dcVanilla :: Bool,
-- True <=> This is a vanilla Haskell 98 data constructor
--          Its type is of form
--              forall a1..an . t1 -> ... tm -> T a1..an
--          No existentials, no coercions, nothing.

There's no explanation why this limitation is introduced; it might be
just a conservative one.

On 20/01/15 15:08, Nicholas Clarke wrote:

> I'd like to be able to use the UNPACK pragma on an existentially
> quantified datatype. So as in the below example:
>
> {-# LANGUAGE ExistentialQuantification #-}
>
> data Foo = forall a. Show a => Foo !a
> instance Show Foo where
>   show (Foo a) = "Foo! " ++ show a
>
> data Bar =
>     Bar {-# UNPACK #-} !Foo
>   deriving (Show)
>
> main :: IO ()
> main = do
>   let foo = Foo "Hello"
>       bar = Bar foo
>   print bar
>
> I would expect the `Foo` constructor to be unpacked into Bar, as if I
> had written:
>
> data Bar = forall a. Show a => Bar !a
>
> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
> argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
> workaround to get it to do so?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Alexander Vershilov
Hi.

As far as I understand  it was fixed as:

commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones <[hidden email]>
Date:   Mon Dec 1 17:07:48 2014 +0000

    Fix parser for UNPACK pragmas

       {-# NOUNPACK #-}
       {-# NOUNPACK #-} !
    were being parsed the same way.  The former was wrong.

    Thanks to Alan Zimmerman for pointing this out


So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.


On 20 January 2015 at 17:35, Roman Cheplyaka <[hidden email]> wrote:

> Interesting question. I managed to trace this to:
>
> compiler/basicTypes/MkId.hs:699
>
> isUnpackableType fam_envs ty
>   | Just (tc, _) <- splitTyConApp_maybe ty
>   , Just con <- tyConSingleAlgDataCon_maybe tc
>   , isVanillaDataCon con
>   = ok_con_args (unitNameSet (getName tc)) con
>   | otherwise
>   = False
>
> where isVanillaDataCon is defined as:
>
> dcVanilla :: Bool,
> -- True <=> This is a vanilla Haskell 98 data constructor
> --          Its type is of form
> --              forall a1..an . t1 -> ... tm -> T a1..an
> --          No existentials, no coercions, nothing.
>
> There's no explanation why this limitation is introduced; it might be
> just a conservative one.
>
> On 20/01/15 15:08, Nicholas Clarke wrote:
>> I'd like to be able to use the UNPACK pragma on an existentially
>> quantified datatype. So as in the below example:
>>
>> {-# LANGUAGE ExistentialQuantification #-}
>>
>> data Foo = forall a. Show a => Foo !a
>> instance Show Foo where
>>   show (Foo a) = "Foo! " ++ show a
>>
>> data Bar =
>>     Bar {-# UNPACK #-} !Foo
>>   deriving (Show)
>>
>> main :: IO ()
>> main = do
>>   let foo = Foo "Hello"
>>       bar = Bar foo
>>   print bar
>>
>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
>> had written:
>>
>> data Bar = forall a. Show a => Bar !a
>>
>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
>> argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
>> workaround to get it to do so?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



--
Alexander
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Roman Cheplyaka-2
How is parsing of the *NOUNPACK* pragma relevant here?

On 23/01/15 10:45, Alexander V Vershilov wrote:

> Hi.
>
> As far as I understand  it was fixed as:
>
> commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
> Author: Simon Peyton Jones <[hidden email]>
> Date:   Mon Dec 1 17:07:48 2014 +0000
>
>     Fix parser for UNPACK pragmas
>
>        {-# NOUNPACK #-}
>        {-# NOUNPACK #-} !
>     were being parsed the same way.  The former was wrong.
>
>     Thanks to Alan Zimmerman for pointing this out
>
>
> So it will fix is in 7.10. And I can't reproduce this anymore on
> ghc-HEAD.
>
>
> On 20 January 2015 at 17:35, Roman Cheplyaka <[hidden email]> wrote:
>> Interesting question. I managed to trace this to:
>>
>> compiler/basicTypes/MkId.hs:699
>>
>> isUnpackableType fam_envs ty
>>   | Just (tc, _) <- splitTyConApp_maybe ty
>>   , Just con <- tyConSingleAlgDataCon_maybe tc
>>   , isVanillaDataCon con
>>   = ok_con_args (unitNameSet (getName tc)) con
>>   | otherwise
>>   = False
>>
>> where isVanillaDataCon is defined as:
>>
>> dcVanilla :: Bool,
>> -- True <=> This is a vanilla Haskell 98 data constructor
>> --          Its type is of form
>> --              forall a1..an . t1 -> ... tm -> T a1..an
>> --          No existentials, no coercions, nothing.
>>
>> There's no explanation why this limitation is introduced; it might be
>> just a conservative one.
>>
>> On 20/01/15 15:08, Nicholas Clarke wrote:
>>> I'd like to be able to use the UNPACK pragma on an existentially
>>> quantified datatype. So as in the below example:
>>>
>>> {-# LANGUAGE ExistentialQuantification #-}
>>>
>>> data Foo = forall a. Show a => Foo !a
>>> instance Show Foo where
>>>   show (Foo a) = "Foo! " ++ show a
>>>
>>> data Bar =
>>>     Bar {-# UNPACK #-} !Foo
>>>   deriving (Show)
>>>
>>> main :: IO ()
>>> main = do
>>>   let foo = Foo "Hello"
>>>       bar = Bar foo
>>>   print bar
>>>
>>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
>>> had written:
>>>
>>> data Bar = forall a. Show a => Bar !a
>>>
>>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
>>> argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
>>> workaround to get it to do so?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Alexander Vershilov

Please take a took at that commit, UNPACK was also handled there, despite commit message do not explicitly state this.

On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <[hidden email]> wrote:
How is parsing of the *NOUNPACK* pragma relevant here?

On 23/01/15 10:45, Alexander V Vershilov wrote:
> Hi.
>
> As far as I understand  it was fixed as:
>
> commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
> Author: Simon Peyton Jones <[hidden email]>
> Date:   Mon Dec 1 17:07:48 2014 +0000
>
>     Fix parser for UNPACK pragmas
>
>        {-# NOUNPACK #-}
>        {-# NOUNPACK #-} !
>     were being parsed the same way.  The former was wrong.
>
>     Thanks to Alan Zimmerman for pointing this out
>
>
> So it will fix is in 7.10. And I can't reproduce this anymore on
> ghc-HEAD.
>
>
> On 20 January 2015 at 17:35, Roman Cheplyaka <[hidden email]> wrote:
>> Interesting question. I managed to trace this to:
>>
>> compiler/basicTypes/MkId.hs:699
>>
>> isUnpackableType fam_envs ty
>>   | Just (tc, _) <- splitTyConApp_maybe ty
>>   , Just con <- tyConSingleAlgDataCon_maybe tc
>>   , isVanillaDataCon con
>>   = ok_con_args (unitNameSet (getName tc)) con
>>   | otherwise
>>   = False
>>
>> where isVanillaDataCon is defined as:
>>
>> dcVanilla :: Bool,
>> -- True <=> This is a vanilla Haskell 98 data constructor
>> --          Its type is of form
>> --              forall a1..an . t1 -> ... tm -> T a1..an
>> --          No existentials, no coercions, nothing.
>>
>> There's no explanation why this limitation is introduced; it might be
>> just a conservative one.
>>
>> On 20/01/15 15:08, Nicholas Clarke wrote:
>>> I'd like to be able to use the UNPACK pragma on an existentially
>>> quantified datatype. So as in the below example:
>>>
>>> {-# LANGUAGE ExistentialQuantification #-}
>>>
>>> data Foo = forall a. Show a => Foo !a
>>> instance Show Foo where
>>>   show (Foo a) = "Foo! " ++ show a
>>>
>>> data Bar =
>>>     Bar {-# UNPACK #-} !Foo
>>>   deriving (Show)
>>>
>>> main :: IO ()
>>> main = do
>>>   let foo = Foo "Hello"
>>>       bar = Bar foo
>>>   print bar
>>>
>>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
>>> had written:
>>>
>>> data Bar = forall a. Show a => Bar !a
>>>
>>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
>>> argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a
>>> workaround to get it to do so?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Roman Cheplyaka-2
I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
changed line (NOUNPACK).

On 23/01/15 10:53, Alexander V Vershilov wrote:

> Please take a took at that commit, UNPACK was also handled there,
> despite commit message do not explicitly state this.
>
> On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     How is parsing of the *NOUNPACK* pragma relevant here?
>
>     On 23/01/15 10:45, Alexander V Vershilov wrote:
>     > Hi.
>     >
>     > As far as I understand  it was fixed as:
>     >
>     > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
>     > Author: Simon Peyton Jones <[hidden email]
>     <mailto:[hidden email]>>
>     > Date:   Mon Dec 1 17:07:48 2014 +0000
>     >
>     >     Fix parser for UNPACK pragmas
>     >
>     >        {-# NOUNPACK #-}
>     >        {-# NOUNPACK #-} !
>     >     were being parsed the same way.  The former was wrong.
>     >
>     >     Thanks to Alan Zimmerman for pointing this out
>     >
>     >
>     > So it will fix is in 7.10. And I can't reproduce this anymore on
>     > ghc-HEAD.
>     >
>     >
>     > On 20 January 2015 at 17:35, Roman Cheplyaka <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >> Interesting question. I managed to trace this to:
>     >>
>     >> compiler/basicTypes/MkId.hs:699
>     >>
>     >> isUnpackableType fam_envs ty
>     >>   | Just (tc, _) <- splitTyConApp_maybe ty
>     >>   , Just con <- tyConSingleAlgDataCon_maybe tc
>     >>   , isVanillaDataCon con
>     >>   = ok_con_args (unitNameSet (getName tc)) con
>     >>   | otherwise
>     >>   = False
>     >>
>     >> where isVanillaDataCon is defined as:
>     >>
>     >> dcVanilla :: Bool,
>     >> -- True <=> This is a vanilla Haskell 98 data constructor
>     >> --          Its type is of form
>     >> --              forall a1..an . t1 -> ... tm -> T a1..an
>     >> --          No existentials, no coercions, nothing.
>     >>
>     >> There's no explanation why this limitation is introduced; it might be
>     >> just a conservative one.
>     >>
>     >> On 20/01/15 15:08, Nicholas Clarke wrote:
>     >>> I'd like to be able to use the UNPACK pragma on an existentially
>     >>> quantified datatype. So as in the below example:
>     >>>
>     >>> {-# LANGUAGE ExistentialQuantification #-}
>     >>>
>     >>> data Foo = forall a. Show a => Foo !a
>     >>> instance Show Foo where
>     >>>   show (Foo a) = "Foo! " ++ show a
>     >>>
>     >>> data Bar =
>     >>>     Bar {-# UNPACK #-} !Foo
>     >>>   deriving (Show)
>     >>>
>     >>> main :: IO ()
>     >>> main = do
>     >>>   let foo = Foo "Hello"
>     >>>       bar = Bar foo
>     >>>   print bar
>     >>>
>     >>> I would expect the `Foo` constructor to be unpacked into Bar, as
>     if I
>     >>> had written:
>     >>>
>     >>> data Bar = forall a. Show a => Bar !a
>     >>>
>     >>> However, instead I get the 'Ignoring unusable UNPACK pragma on
>     the first
>     >>> argument of ‘Bar’' warning. Is there a reason this shouldn't
>     work, or a
>     >>> workaround to get it to do so?
>     >>
>     >> _______________________________________________
>     >> Glasgow-haskell-users mailing list
>     >> [hidden email]
>     <mailto:[hidden email]>
>     >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>     >
>     >
>     >
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: UNPACK Existential datatype

Alexander Vershilov
Very strange, I was referring to:

git show 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27

commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones <[hidden email]>
Date:   Mon Dec 1 17:07:48 2014 +0000

    Fix parser for UNPACK pragmas

       {-# NOUNPACK #-}
       {-# NOUNPACK #-} !
    were being parsed the same way.  The former was wrong.

    Thanks to Alan Zimmerman for pointing this out

diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
index e3f82ce..c7143ae 100644
--- a/compiler/parser/Parser.y
+++ b/compiler/parser/Parser.y
@@ -1350,11 +1350,11 @@ sigtypes1 :: { (OrdList (LHsType RdrName)) }
   -- Always HsForAllTys
 -- Types

 strict_mark :: { Located ([AddAnn],HsBang) }
-        : '!'                        { sL1 $1 ([],HsUserBang Nothing
    True) }
-        | '{-# UNPACK' '#-}'         { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just True)  False) }
-        | '{-# NOUNPACK' '#-}'       { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just False) True) }
-        | '{-# UNPACK' '#-}' '!'     { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just True)  True) }
-        | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just False) True) }
+        : '!'                        { sL1 $1    ([],
HsUserBang Nothing      True) }
+        | '{-# UNPACK' '#-}'         { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just True)  False) }
+        | '{-# NOUNPACK' '#-}'       { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just False) False) }
+        | '{-# UNPACK' '#-}' '!'     { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just True)  True) }
+        | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just False) True) }
         -- Although UNPACK with no '!' is illegal, we get a
         -- better error message if we parse it here

I'm not sure that is there were no other commits that that are
related to the issue. TBH, I can't see warnings for this example
program  that was mentioned in this thread using GHC-HEAD,
but having either `{-# UNPACK #-} !` or `!` or `{-# UNPACK #-}`
do not change core output, regardless whether -fno-unbox-small-strict-fields
or -fno-unbox-strict-fields provided or not.


On 23 January 2015 at 11:59, Roman Cheplyaka <[hidden email]> wrote:

> I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
> changed line (NOUNPACK).
>
> On 23/01/15 10:53, Alexander V Vershilov wrote:
>> Please take a took at that commit, UNPACK was also handled there,
>> despite commit message do not explicitly state this.
>>
>> On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     How is parsing of the *NOUNPACK* pragma relevant here?
>>
>>     On 23/01/15 10:45, Alexander V Vershilov wrote:
>>     > Hi.
>>     >
>>     > As far as I understand  it was fixed as:
>>     >
>>     > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
>>     > Author: Simon Peyton Jones <[hidden email]
>>     <mailto:[hidden email]>>
>>     > Date:   Mon Dec 1 17:07:48 2014 +0000
>>     >
>>     >     Fix parser for UNPACK pragmas
>>     >
>>     >        {-# NOUNPACK #-}
>>     >        {-# NOUNPACK #-} !
>>     >     were being parsed the same way.  The former was wrong.
>>     >
>>     >     Thanks to Alan Zimmerman for pointing this out
>>     >
>>     >
>>     > So it will fix is in 7.10. And I can't reproduce this anymore on
>>     > ghc-HEAD.
>>     >
>>     >
>>     > On 20 January 2015 at 17:35, Roman Cheplyaka <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>     >> Interesting question. I managed to trace this to:
>>     >>
>>     >> compiler/basicTypes/MkId.hs:699
>>     >>
>>     >> isUnpackableType fam_envs ty
>>     >>   | Just (tc, _) <- splitTyConApp_maybe ty
>>     >>   , Just con <- tyConSingleAlgDataCon_maybe tc
>>     >>   , isVanillaDataCon con
>>     >>   = ok_con_args (unitNameSet (getName tc)) con
>>     >>   | otherwise
>>     >>   = False
>>     >>
>>     >> where isVanillaDataCon is defined as:
>>     >>
>>     >> dcVanilla :: Bool,
>>     >> -- True <=> This is a vanilla Haskell 98 data constructor
>>     >> --          Its type is of form
>>     >> --              forall a1..an . t1 -> ... tm -> T a1..an
>>     >> --          No existentials, no coercions, nothing.
>>     >>
>>     >> There's no explanation why this limitation is introduced; it might be
>>     >> just a conservative one.
>>     >>
>>     >> On 20/01/15 15:08, Nicholas Clarke wrote:
>>     >>> I'd like to be able to use the UNPACK pragma on an existentially
>>     >>> quantified datatype. So as in the below example:
>>     >>>
>>     >>> {-# LANGUAGE ExistentialQuantification #-}
>>     >>>
>>     >>> data Foo = forall a. Show a => Foo !a
>>     >>> instance Show Foo where
>>     >>>   show (Foo a) = "Foo! " ++ show a
>>     >>>
>>     >>> data Bar =
>>     >>>     Bar {-# UNPACK #-} !Foo
>>     >>>   deriving (Show)
>>     >>>
>>     >>> main :: IO ()
>>     >>> main = do
>>     >>>   let foo = Foo "Hello"
>>     >>>       bar = Bar foo
>>     >>>   print bar
>>     >>>
>>     >>> I would expect the `Foo` constructor to be unpacked into Bar, as
>>     if I
>>     >>> had written:
>>     >>>
>>     >>> data Bar = forall a. Show a => Bar !a
>>     >>>
>>     >>> However, instead I get the 'Ignoring unusable UNPACK pragma on
>>     the first
>>     >>> argument of ‘Bar’' warning. Is there a reason this shouldn't
>>     work, or a
>>     >>> workaround to get it to do so?
>>     >>
>>     >> _______________________________________________
>>     >> Glasgow-haskell-users mailing list
>>     >> [hidden email]
>>     <mailto:[hidden email]>
>>     >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>     >
>>     >
>>     >
>>
>



--
Alexander
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: UNPACK Existential datatype

Simon Peyton Jones
In reply to this post by Nicholas Clarke

I think this is a very reasonable suggestion.  It would take some work to implement, but nothing fundamental.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Nicholas Clarke
Sent: 20 January 2015 13:08
To: [hidden email]
Subject: Fwd: UNPACK Existential datatype

 

I'd like to be able to use the UNPACK pragma on an existentially quantified datatype. So as in the below example:

 

{-# LANGUAGE ExistentialQuantification #-}

 

data Foo = forall a. Show a => Foo !a

instance Show Foo where

  show (Foo a) = "Foo! " ++ show a

 

data Bar =

    Bar {-# UNPACK #-} !Foo

  deriving (Show)

 

main :: IO ()

main = do

  let foo = Foo "Hello"

      bar = Bar foo

  print bar

 

I would expect the `Foo` constructor to be unpacked into Bar, as if I had written:

 

data Bar = forall a. Show a => Bar !a

 

However, instead I get the 'Ignoring unusable UNPACK pragma on the first argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a workaround to get it to do so?

 

Cheers,

 

Nick

 

 


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users