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
> 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
> 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
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
[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
> 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
> 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
> 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
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
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
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
11 matches
Mail list logo