Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)

Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-08-25 19:53:45

On 25 August 2015 at 19:50, Niall Douglas <s_sourceforge_at_[hidden]> wrote:

> On 25 Aug 2015 at 17:49, Paul A. Bristow wrote:
>
> > > But let me clear, if anyone can suggest a similarly short, instantly
> > > recognisable, uniquely standout name for monad<T>, I'm all ears.
> >
> > OK - here's a concrete suggestion.
> > [snip]
> > these are all *outcomes* - of varying types of varying and unspecified
> Thingy.
> >
> > So rather than Thingy or Donkey, how about:
> >
> >   Outcome<R>
>
> I like Boost.Outcome and boost::outcome::basic_outcome<Policy>.
>
> Do these make sense however:
>
> outcome<T>: Can be empty/T/error_code/exception_ptr.
>
> result<T>: Can be empty/T/error_code.
>
> option<T>: Can be empty/T.
>
> If people like this, I can change Boost.Monad to Boost.Outcome very
> easily.
>
> Niall
>

A potential user POV:

1. I agree with Giovanni Piero Deretta and Andrey Semashev, to me (even
without having done any concrete Haskell
   but after having learned what is a monad in the abstract/mathematical
sense),
   I see naming a _type_ "monad" as very obscure as it does not tell me
what it does, just part of how it works.
   It's exactly like if std::vector was named std::container as already
mentioned and that's exactly what I was
   thinking when reading the previous discussions on the subject. I didn't
say anything because when talking about monads it's very
   easy to endup with a confusing discussion.
2. I disagree with the naming argument you gave so far, mainly because it
seems that only you believe in it (but I might be wrong)
    and your arguments don't rely on logic, observation or popularity (but
my pov is less important than specialists around here, and naming is hard
etc.)
3. I have no problem with a _library_ that would be named Boost.Monad if it
provides different types using this useful ...err..."pattern", like
optional,
    future and the thing you are trying to name at the moment. It's with a
type named monad that it is very confusing.
4.  'outcome' seems reasonable, it's a little vague but there was no more
specific propositons so far and it seems to suggest the way it is used.
     It feels like a more general expected. There might be a more
apropriate name or a neologism to be made though.

Hope it helps.

Joël Lamotte