It seems like you would, going by semantics of System F, where types
with type variables name a certain subset of types, = constraints
further restrict the types of the same shape (are they an
independent kind of restriction?), so typeclass declarations
with/without = specify a partial order over
Haskell does not play as well with overloading as one would do it in C++;
every
name used must be fully qualified. Indeed, if we try something like
Indeed, if we try something like
data A = A Int deriving (Show, Eq)
test = A 3 unA (A i) = i
class Group a where (+) :: a - a - a
instance Group
Thank you for highlighting these problems; I should really test my own code
more thoroughly. After reading these most recent examples, the translation
to
existing monads is definitely too neat, and a lot of semantics of the monad
are
'defaulted' on. In particular for the probability monad examples
of autolifting.
On Tue, Nov 16, 2010 at 2:49 AM, o...@okmij.org wrote:
Ling Yang wrote
I think a good question as a starting point is whether it's possible
to do this 'monadic instance transformation' for any typeclass, and
whether or not we were lucky to have been able to instance Num so
easily
Hi,
I'm fairly new to Haskell and recently came across some programming
tricks for reducing monadic overhead, and am wondering what
higher-level concepts they map to. It would be great to get some
pointers to related work.
Background:
I'm a graduate student whose research interests include
...@uptoisomorphism.net wrote:
On Mon, Nov 15, 2010 at 12:43 PM, Ling Yang ly...@cs.stanford.edu wrote:
Specifically: There are some DSLs that can be largely expressed as monads,
that inherently play nicely with expressions on non-monadic values.
We'd like to use the functions that already work
