Subject: Re: [boost] Monad
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-08-25 14:07:57
Le 25/08/15 14:44, Niall Douglas a écrit :
> 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.
Clearly you are missing the point. You class monad could be seen as a
model of a Monad (but don't as it doesn't defines a generic
unit/return_/make function) as others can.
I would say that your monad class is something close to an instantiation
of a variadic expected
expected<T, E1, ... En>
After some request I'm thinking in extending expected<T,E> to variadic
templates. expected<T, E1, ... En> would be something like
variant<T, unexpected<E1>, ... unexpected<En>>
Your class would be something like
expected<T, empty, error_code, exception_ptr>
with some specific interfaces. Am I missing something?
P.S. Note that you can already have
expected<T, variant<empty, error_code, exception_ptr>>
The variadic version would be be more efficient and with a more friendly
>> 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 (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 .
> C++ is not a functional programming language and never will be, and I
> even think nor should it be.
Hmm, I prefer to don't replay here, as I don't know what you understand
by a functional programming and I can not divine what C++ will be in the
I can not understand why do you think it shouldn't be one but I respect
your opinion however.
> 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?
because naming is important.
> 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
It seems that not too much people agree with your point of view. Maybe
it is time you consider what other are saying.
> 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.
If you don't like expected<T>, I will suggest you to name it
> For example, I have toyed with donkey<T> instead of monad<T>. Also a
> nonsense name, but it does the donkey work of exception safety for
> you (with monadic programming extensions) and it has all the features
> of standing out from surrounding code, being quick to type and so on.
> Would people prefer Boost.Monad => Boost.Donkey, and monad<T> =>
> The reason I didn't choose donkey<T> is because I thought people
> wouldn't take a Boost.Donkey library seriously, and that would be a
> shame as I'm finding it an enormous productivity aid. It also doesn't
> fit to have a lightweight fast Concurrency TS implementation in a
> library called Boost.Donkey.
> But I also don't think the naming war on this library can be won. If
> Boost.Donkey will stop the war and make people vote for acceptance,
> I'll take Boost.Donkey over Boost.Monad any day.
As you can see choosing the good names has its importance. With a good
name we would be reviewing the concrete features already.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk