-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas Sent: 25 August 2015 13:44 To: boost@lists.boost.org 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 +44 (0) 1539 561830