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: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-08-25 12:49:08

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Niall Douglas
> Sent: 25 August 2015 13:44
> To: boost_at_[hidden]
> Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
> 
> On 25 Aug 2015 at 0:02, Giovanni Piero Deretta wrote:
> 
> > > It's a C++ monad designed for C++ programmers writing in C++.
> >
> > Niall, you are missing the point: the reason that your monad can't be
> > the true definition of a Monad is that no type can.
> 
> No, that's exactly why I chose that name for the library. I absolutely get the point.
> 
> > That there is no
> > such a thing as Monad type in Haskell at all; there is a type *class*
> > named Monad.  In Haskell there are many concrete types that are
> > instances of the Monad type class (list, Maybe, IO). Other languages
> > are similar: I believe you are familiar with rust, in that language
> > Monad would be a trait.
> >
> > Similarly, in C++ you can have multiple types[1] (option, future,
> > etc...) that model the Monad concept (Haskell type classes loosely map
> > to C++ concepts), but calling any of them (or a template type) a
> > Monad, makes at much sense as having a class named RegularType.
> 
> Again, exactly why I chose it: it makes no sense.
> 
> > In C++, you could argue that 'monad' would be a decent name for type
> > erased wrapper over any type that model the Monad concept, but I do
> > not believe that your monad type is that.
> >
> > Now, afio::monad, while not great, at least suggests that we are
> > talking about the Monad of Asynchronous File IO [2].
> 
> C++ is not a functional programming language and never will be, and I
> even think nor should it be.
> 
> I certainly don't get anything like as worked up about naming as
> people are getting over this. Who cares if it doesn't pollute
> namespace, is short to type and isn't going to get confused with
> something else?
> 
> That's why value<T> or holder<T> or return_<T> all got ruled out.
> They will confuse. monad<T> is nonsense name, but it stands out
> nicely in code and let's the eye quickly check that your logic is
> correct.
> 
> As monad<T>'s main use case for me so far at least is exception
> safety management, it NEEDS to stand out from surrounding code as a
> return type from a function.
> 
> 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.

If I've understood correctly from this

Predefined basic_monad implementations:
<dl>
  <dt>`monad<R>`</dt>
    <dd>Can hold a fixed variant list of empty, a type `R`, a lightweight `std::error_code` or a
heavier `std::exception_ptr` at a space cost of `max(24, sizeof(R)+8)`. This corresponds to
`tribool::unknown`,
`tribool::true_`, `tribool::false_` and `tribool::false_` respectively.</dd>
  <dt>`result<R>`</dt>
    <dd>Can hold a fixed variant list of empty, a type `R` or a lightweight `std::error_code` at a
space cost of `max(24, sizeof(R)+8)`. This corresponds to `tribool::unknown`, `tribool::true_` and
`tribool::false_` respectively. This specialisation looks deliberately like Rust's `Result<T>`.</dd>
  <dt>`option<R>`</dt>
    <dd>Can hold a fixed variant list of empty or a type `R` at a space cost of
`sizeof(value_storage<R>)`
which is usually `sizeof(R)+8`, but may be smaller if `value_storage<R>` is specialised e.g.
`sizeof(option<char>)` is just two bytes, and `sizeof(option<bool>)` is just one byte (see note
about
`option<bool>` below). This corresponds to `tribool::unknown` and `tribool::true_`
respectively. This specialisation looks deliberately like Rust's `Option<T>`.</dd>
</dl>

these are all *outcomes* - of varying types of varying and unspecified Thingy.

So rather than Thingy or Donkey, how about:

  Outcome<R>

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]