RE: fundeps for extended Monad definition

2003-02-27 Thread Simon Peyton-Jones
Interesting example | class Monad2 m a ma | m a -> ma, ma -> m a where | return2 :: a -> ma | bind2 :: Monad2 m b mb => ma -> (a -> mb) -> mb | _unused :: m a -> () | _unused = \_ -> () | instance Monad2 [] a [a] where | bind2 = error "urk" The functional dependencies say

escape from existential quantification

2003-02-27 Thread Wang Meng
I understand that existentially bound types cannot escape. For example, say we have data Foo = forall a. Foo Int a Then we cannot define a function extract (Foo i a) = a However,this limitation makes it extremly difficult to program with local quantifications.Is there any way to by pass this?

fundeps known beforehand (was RE: fundeps for extended Monad definition)

2003-02-27 Thread Hal Daume III
Hi Simon, all, > Here's a less complicated variant of the same problem: > > class C a b | a -> b where {} > > instance C Int Int where {} > > f :: (C Int b) => Int -> b > f x = x This is interesting, but I'm not entirely sure what the problem is (from a theoretical, not

Re: escape from existential quantification

2003-02-27 Thread Keith Wansbrough
> I understand that existentially bound types cannot escape. > > For example, say we have > data Foo = forall a. Foo Int a > > Then we cannot define a function > extract (Foo i a) = a > > However,this limitation makes it extremly difficult to program with local > quantifications.Is there any way

Re: escape from existential quantification

2003-02-27 Thread Nick Name
On Thu, 27 Feb 2003 18:26:31 + Keith Wansbrough <[EMAIL PROTECTED]> wrote: > > The idea is to use a type more like this: > > data Foo = forall a. Foo Int a (a -> (Int,Bool)) (a -> Int) (a -> > Foo) > > where the functions are the operations you want to use on the data Or else one can u

Re : escape from existential quantification

2003-02-27 Thread George Russell
Wang Meng wrote I understand that existentially bound types cannot escape. For example, say we have data Foo = forall a. Foo Int a Then we cannot define a function extract (Foo i a) = a However,this limitation makes it extremly difficult to program with local quantifications.Is there any way to by

Re: Re : escape from existential quantification

2003-02-27 Thread Hal Daume III
> It occasionally happens that I *know* what type is (or at least ought to be) inside > an existential type, but unfortunately GHC doesn't, and I need to get the value out. > This can be solved using dynamic types, for example you declare the datatype as You can also use an unsafe cast operation i

Announce: Haskell Data Clustering

2003-02-27 Thread Hal Daume III
Hi all, I've had some software which implements a variety of unsupervised learning (aka clustering) algorithms around for some time, but finally got around to making the source code available. I thought some people on this list might find it of interest, so I include a pointer which explains how

RE: fundeps for extended Monad definition

2003-02-27 Thread oleg
Hello! Simon Peyton-Jones wrote: > class C a b | a -> b where {} > instance C Int Int where {} > f1 :: (forall b. (C Int b) => Int -> b) > f1 x = undefined Indeed, this gives an error message Cannot unify the type-signature variable `b' with the type `Int' Expected type: Int

Re: fundeps known beforehand (was RE: fundeps for extended Monad definition)

2003-02-27 Thread Hal Daume III
> Suppose we are in case 1. Then the programmer has written a too-general > type signature on f. The programmer *must* know that b=Int in this case > otherwise his function definition makes no sense. However, I don't really > see a reason why this should be an error rather than just a warning.

RE: fundeps for extended Monad definition

2003-02-27 Thread Hal Daume III
> The reason, which is thoroughly explained in Simon Peyton-Jones' > message, is that the given type signature is wrong: it should read > f1 :: (exists b. (C Int b) => Int -> b) Sigh, read this after posting :) ___ Haskell mailing list [EMAIL PROT