unresolved top level overloading

1998-07-09 Thread S. Alexander Jacobson
What does unresolved top level overloading mean in this context? > data Oracle = Oracle > data OracleConnection = OracleConnection > class DBMS dbms where > nameDBMS::dbms->String > class DBConnection c where > openConnection::(DBMS dbms) => dbms -> String -> c > nameConnection:: c -> String

Re: type synonyms

1998-07-09 Thread Simon L Peyton Jones
> That's basically newtype with the data constructor omitted (I would > prefer data to record). Unfortunately, this seems to be incompatible > with the class system. (There was a long discussion on the Standard > Haskell discussion list, unfortunately the entry vanished). No, it just moved over

Re: type synonyms

1998-07-09 Thread Ralf Hinze
> data / type / newtype: > > i'd like to have these choices > > type T1 = record C1 .. | C2 .. > type T2 = T1 > type T3 = new T2 > > with T2 identical to T1, > and T3 being an identical copy of T2 (but different from T2) > inheriting all its constructors and operations. That's basically newty

Re: type synonyms

1998-07-09 Thread Johannes Waldmann
data / type / newtype: i'd like to have these choices type T1 = record C1 .. | C2 .. type T2 = T1 type T3 = new T2 with T2 identical to T1, and T3 being an identical copy of T2 (but different from T2) inheriting all its constructors and operations. (at the moment, type .. = record .. is writt

Re: type synonyms

1998-07-09 Thread Martin Stein
[I send it to [EMAIL PROTECTED] because it's more appropriate] > And I think it's a good idea to allow type synomyms!! After all that's > what they are made for: to abbreviate type expression or to give an > indication what the type is used for. I think, that this isn't sufficient. There are two

Re: monad transformers and lift

1998-07-09 Thread Ralf Hinze
> Suppose I have the following class of monad transformers: > > class (Monad m, Monad (t m)) => MonadT t m where > lift :: m a -> t m a > > and several instances of the class: > > instance MonadT MT1 where ... > instance MonadT MT2 where ... > . . . > instance MonadT MTn where ... > > I obta

Re: monad transformers and lift

1998-07-09 Thread Keith S. Wansbrough
> I obtain a new monad composing monad transformers through the IO monad: > > type MyMonad = MT1 (MT2 (... (MTn IO))) > > And now, if I want to lift "putStrLn" I must write: > > myPutStrLn = lift . lift . ... lift . putStrLn > > This works but looks ugly. > > The question is: > Is there a wa

Re: monad transformers and lift

1998-07-09 Thread Johannes Waldmann
> And now, if I want to lift "putStrLn" I must write: > > myPutStrLn = lift . lift . ... lift . putStrLn > > This works but looks ugly. > Another problem is when some of the monad transformers provide the same > functions, for example, if MTi also provides "putStrLn", How could I tell > the

monad transformers and lift

1998-07-09 Thread Jose Emilio Labra Gayo
Suppose I have the following class of monad transformers: class (Monad m, Monad (t m)) => MonadT t m where lift :: m a -> t m a and several instances of the class: instance MonadT MT1 where ... instance MonadT MT2 where ... . . . instance MonadT MTn where ... I obtain a new monad composing

Re: multi param type classes

1998-07-09 Thread Fergus Henderson
On 08-Jul-1998, Mariano Suarez Alvarez <[EMAIL PROTECTED]> wrote: > On Wed, 8 Jul 1998 [EMAIL PROTECTED] wrote: > > > Each expression then has a set of possible types, and the ambiguity is > > resolved by an explicit type signature. > > > > At present it is quite frustrating in Haskell that w

Re: multi param type classes

1998-07-09 Thread Fergus Henderson
On 08-Jul-1998, Johannes Waldmann <[EMAIL PROTECTED]> wrote: ... > how would you resolve ambiguities? > probably by requiring an explicit type signature > at the point of usage. > > fine, but then i'd like to have this in other cases as well, > finally arriving at Ada-style overloading > (a name