It's (sadly) still not possible to express monads with this change, since generic methods can't implement interfaces. You'd probably want something like:
type Monad[T any] interface {
Bind[U any](func(T) Monad[U])
}
However this requires the Bind method to be generic, which still isn't allowed in an interface
I am not very familiar with Go and especially not its generics support. Can you implement the "join" version instead of the "bind" version, where you turn a T[T[a]] into a T[a]?
> Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science.
No contributor to Go is responsible for "introducing monads to computer science", as the Monad concept is a member of (or defined by if you prefer) Category Theory[0].
As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. The paper usually credited with that is: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b... Which the parent rightfully points out was written by the same person primarily responsible for the design of generics in Go: https://homepages.inf.ed.ac.uk/wadler/topics/go.html
> As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science.
With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares:
The concept of a monad, which arises from category theory,
has been applied by Moggi to structure the denotational
semantics of programming languages.
Therefore, one cannot assert that a computer scientist whom identifies a predecessor's contributions such as above is, in fact, responsible for said contributions.
And with full respect also given to Moggi, introductions are only introductions if they are heard.
If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, by all appearances, what caught the attention of the computer science community. "Monads for functional programming" is regularly cited as the seminal paper. They are strongly associated with Haskell. It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
> If we were talking about the first person to discover monads, Wadler clearly would not be he.
We are not. Remember what the OP stated, to which I originally replied:
Funnily enough, Go's generics were designed by the same guy
who introduced monads to computer science.
This is demonstrably incorrect, as Wadler did not "introduce monads to computer science" and is what I disagreed with alone.
Did Wadler take monads to new and important levels in both computer science and software engineering? Absolutely!
> It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
I quoted the Moggi attribution due to it being present in the paper you kindly provided. Whether Moggi has any influence socially is irrelevant as it pertains to the original thesis discussed above.
> If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
Again, this is not germane to the aforementioned OP statement.
> Can we have Exception monads? Asking for friend.
This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0].
Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2].
I don't think it's nonsensical, it's just another name for the same thing. E.g. in the Haskell wiki it says, "the Error monad, also called the Exception monad".
I was unaware of "Exception monad" being an industry equivalent term for Either/Error. Given no other context, desiring an "Exception monad" could be interpreted as "a type which handles raising Exception types." Which is how I did.
Was a desire to have "a type which handles raising Exception types." Until now, I was unaware of "Exception monad" being an alternate moniker for Either/Error types.