On 2013-12-04 08:24:02 +0000, qznc said:

> On Wednesday, 4 December 2013 at 01:53:39 UTC, Shammah Chancellor wrote:
>> Or is D syntax not generic enough to define monads?
> 
> I started to port monads to D [0]. You can do it, but it looks ugly. The trick is to implement (Haskell) type classes via template specialization. I came to the conclusion that it is not worth it.
> 
> What D kind of lacks is a way to define a general type class aka the interface. Of course, you could use the "interface" keyword, but then you cannot apply it to structs. Haskell has no structs (value type records), so they do not have this problem. Look at how isInputRange is implemented [1]. The traits in Rust [2] provide this interface mechanisms as a language feature. D uses static-if instead.
> 
> Not Haskell, not D, not Rust can check, if your monad actually follows the monad laws [3]. This would probably require a full theorem prover in your language. So Coq, Isabelle, and maybe ATS could do that. A similar challenge would be to check if a user-defined plus operator is commutative (a+b == b+a) like arithmetic plus operations.
> 
> [0] https://bitbucket.org/qznc/d-monad/src/5b9d41c611093db74485b017a72473447f8d5595/generic.d?at=master 
> 
> [1] https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#L519 
> 
> [2] http://static.rust-lang.org/doc/0.8/tutorial.html#generics
> [3] http://www.haskell.org/haskellwiki/Monad_laws

I was talking on the D newsgroup about using an interface type and implementing isConceptOf!(<interface>) to be used with structs.    Wouldn't that fix the problem?

-Shammah

On Wednesday, 4 December 2013 at 12:08:32 UTC, Shammah Chancellor wrote:
> I was talking on the D newsgroup about using an interface type and implementing isConceptOf!(<interface>) to be used with structs.    Wouldn't that fix the problem?
>
> -Shammah

No. D does not check if code of template actually conforms its constraint. You can still call functions that are not guaranteed to be there by constraint thus it is not really a type class / concept, just syntax convenience for constraint.

On Wednesday, 4 December 2013 at 10:03:51 UTC, Timon Gehr wrote:
> On 12/04/2013 12:49 AM, Max Klyga wrote:
>>
>>
>> range.map(...).flatten.map(...) might look similar and it could be
>> possible to squeeze monads to work with this api,  but the thing is that
>> not every monad could provide a meaningful map function
>
> Yes, every monad provides a meaningful way to map morphisms.
>
> In Haskell this is not explicit however:
>
> map :: Monad m => (a -> b) -> m a -> m b
> map f = (return . f =<<)
>
>> and as a whole
>> calling flatten after every map is a bit tiresome.

You are right. Now looking at provided implementation this seems obvoius

On Wednesday, 4 December 2013 at 08:24:03 UTC, qznc wrote:
> On Wednesday, 4 December 2013 at 01:53:39 UTC, Shammah Chancellor wrote:
>> Or is D syntax not generic enough to define monads?
>
> I started to port monads to D [0]. You can do it, but it looks ugly. The trick is to implement (Haskell) type classes via template specialization. I came to the conclusion that it is not worth it.
>
> What D kind of lacks is a way to define a general type class aka the interface. Of course, you could use the "interface" keyword, but then you cannot apply it to structs. Haskell has no structs (value type records), so they do not have this problem. Look at how isInputRange is implemented [1]. The traits in Rust [2] provide this interface mechanisms as a language feature. D uses static-if instead.

D uses static if and template constraints for typeclass/concept checking because one cannot add specializations to templates defined in other modules. Using template specialization for defining type class instances would render them not extensible for users