3 ms·

Honestly the main feature of Haskell in this regard isn't STM-colored functions (as you note, that's a bad thing), but rather that it almost supports color-gene

by a1369209993 6y ago

Honestly the main feature of Haskell in this regard isn't STM-colored functions (as you note, that's a bad thing), but rather that it almost supports color-generic functions in the form of `Monad f => A -> f B -> f C`. Unfortunately, it doesn't correctly handle the identity monad `type Id a = a`, instead requiring `newtype Id a = Id a`, so it's impossible to write a function that matches both (eg) `A -> B` and `Monad f => A -> f B`.

kccqzy 6y ago
I don't understand your argument. It is correct that the standard library provides you with a newtype-based identity monad. But as you have said, you can also write own `type Id a = a`. What's wrong with that?
- a1369209993 6y ago
  > What's wrong with [`type Id = a`]? The fact that it doesn't work: > - The type synonym 'Id' should have 1 argument, but has been given none > - In the instance declaration for 'Monad Id' > | instance Monad Id where
  - kccqzy 6y ago
    Of course that won't work because that type synonym is far from a monad. I think you meant to write `type Id a = a` or `type Id f a = f a` instead. But I get your argument now. What you are saying is that we want some kind of a way to define functions that are either pure or return a monadic value. Currently that's not doable because these two have distinct types. It may be difficult to unify them via the type system. This is even more difficult for higher-order functions that take other functions.
    - a1369209993 6y ago
      > I think you meant to write `type Id a = a` Indeed I did, sorry, unfortunately too late to edit. The following reproduces the error: {-# LANGUAGE TypeSynonymInstances #-} type Id a = a instance Monad Id where x >>= f = f x return = id (The last two lines can be ommitted, since GHC aborts before checking the instance body. Edit: which is why I didn't notice I had the arguments to >>= backward; fixed?) > It may be difficult to unify them via the type system. This is even more difficult for higher-order functions that take other functions. IMO, the main difficulty in unifying `a ~ Monad m => m a` is inferring `m ~ \a1-> a1` in a way that allows `\a1-> a1` to inherit `Id`'s instances. It's a understandable deficiency, but it is a deficiency.
AaronFriel 6y ago
I think Haskell enforcing a separation between the "color" (or monad) of functions is generally good.

kccqzy 6y ago

I don't understand your argument. It is correct that the standard library provides you with a newtype-based identity monad. But as you have said, you can also write own `type Id a = a`. What's wrong with that?

a1369209993 6y ago
> What's wrong with [`type Id = a`]? The fact that it doesn't work: > - The type synonym 'Id' should have 1 argument, but has been given none > - In the instance declaration for 'Monad Id' > | instance Monad Id where
- kccqzy 6y ago
  Of course that won't work because that type synonym is far from a monad. I think you meant to write `type Id a = a` or `type Id f a = f a` instead. But I get your argument now. What you are saying is that we want some kind of a way to define functions that are either pure or return a monadic value. Currently that's not doable because these two have distinct types. It may be difficult to unify them via the type system. This is even more difficult for higher-order functions that take other functions.
  - a1369209993 6y ago
    > I think you meant to write `type Id a = a` Indeed I did, sorry, unfortunately too late to edit. The following reproduces the error: {-# LANGUAGE TypeSynonymInstances #-} type Id a = a instance Monad Id where x >>= f = f x return = id (The last two lines can be ommitted, since GHC aborts before checking the instance body. Edit: which is why I didn't notice I had the arguments to >>= backward; fixed?) > It may be difficult to unify them via the type system. This is even more difficult for higher-order functions that take other functions. IMO, the main difficulty in unifying `a ~ Monad m => m a` is inferring `m ~ \a1-> a1` in a way that allows `\a1-> a1` to inherit `Id`'s instances. It's a understandable deficiency, but it is a deficiency.

AaronFriel 6y ago

I think Haskell enforcing a separation between the "color" (or monad) of functions is generally good.