Fair enough. It's important to have some solidarity in terminology, because as first adopters and early language writers, we have an amplified influence over the future of idiomatic Elm.
But sometimes I might want to be able to say that something "is monadic", if I felt that it's a major feature or focus of the library. My state library, for example, really isn't interesting except for the fact that it implements the Monad pattern. This particular library is actually quite clumsy to use if you don't use desugared-do-block style.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
But the HTTP proposal is monadic. When we're talking about API design, I don't want to censor myself from mentioning "hey look, that type is monadic" just because some people are unfamiliar with why that might be evidence of good design.
And sometimes monads have nothing to do with effects. But they share a common, incredibly useful pattern of control flow. We can keep it out of the standard libs, but I very much doubt that we can purge monads from the public user libraries or the realm of lost discussion. And I don't think we should.
I strongly disagree!I think the question is "what are you going to call SomeAbstraction?" is, and I think the answer is not one universally appropriate answer. That is, the answer is neither 1) "Don't call X a monad!" nor 2) "Call X a monad!".Those two answers are blind guidelines/recommendations/rules. They are missing context, and time.The following is the situation I think you're referring to: Say Alice doesn't know about monads, and she comes and asks me "What is this SomeAbstraction thing?, I want to use it!", then if I answer "It's a Monad", my answer will be quite unhelpful, even if I then explain what monads are! Why? Because it is one instance of something general which Alice just found out about.
In that situation, you are right.But now consider this situation: Bob wrote a bunch of code years ago, and now I have to look at it and maintain it. I've no idea what any of it does. But the phrase "X and Y, and Z, are monads" (and the types, of course!) gives me so much information that I can make sense of a great deal of the codebase.I've been in this last situation several times."X is a {insert kind of functor, i.e. applicative, monad, etc}" can be extremely useful and information-rich. It literally tells you, in a word, about a whole "interface" and capabilities something has (and doesn't).Let's not set a universal rule against a word just because it can be used unwisely.
On Friday, May 2, 2014 5:35:51 PM UTC-3, Evan wrote:I really don't want to call things the ___ monad! (e.g. the IO monad, the state monad, etc.)
Haskell people (including me) always say things like, "To print things out you need to use the IO monad." This is like saying, "To add numbers you need to use the Addition Group."It's just really weird to describe the algebraic properties of the thing in it's name. It also focuses on characteristics you don't need to fully appreciate to be able to use and understand the particular instance. You don't need to understand group theory or field theory to do addition and multiplication, and this is a good thing! Group theory deepens that understanding, but it is non-essential to being able to do basic math.
In both these cases, we made something simple sound magical and complex. I want Elm people to say "To print things out, use the IO library" and to make it parallel "To add numbers, use addition."
--
Haha don't worry it was me too with my state monad package.
Evan, despite the position I took in my previous mails, I'm still giving serious consideration to what you're saying, and I do like your PR.
--
Re: group theory. We do actually say things like "the dihedral group" or "the spin group".
At the same time I feel like there's a lot of talk about how scary it is to hear the word monad and that's why it shouldn't be used. Lots of words in programming are scary to me but I knew what a monad was before I started programming so that's not one of them :-)
algebraic properties of particular data structures
That does not even matter though. No matter who it is, we need to treat each other with respect, especially when we disagree. The fact that we have people with reasonably diverse backgrounds and opinions on this list is a huge boon to Elm.