Re: [boost] [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-08-01 06:29:02

> I could rip out all methods except their minimal complete definition from
> every type class, and have those other methods be "algorithms that require
> instances of the type class". However, you can now only have a single
> minimal
> complete definition for each type class, which is less flexible. Let's
> pretend
> that you can somehow have multiple MCDs. Now, the default definition of
> the
> algorithms that were ripped out can't depend on that MCD, because they are
> out
> of the type class. That's another loss of flexibility. All in all, I see
> no
> gains and only losses in ripping out methods from the type classes. 

Of course, you don't have to rip out every default method. It makes sense to
keep some when you have multiple MCDs.

> If you can explain to me what your proposal allows that can't be done
> right now, I'm open for discussion.

Of course, you can achieve that already in your library, but what I'm
proposing is to separate the two purposes you have for implementing
typeclasses. Instead, the user would implement a typeclass to fulfill type
requirements, and would overload an algorithm to provide optimizations.

> I really don't think the same advice can be applied here, and I don't see
> why it should. Type classes and regular structs are conceptually very
> different entities, even if they are implemented in the same way. 

Perhaps, the advice doesn't directly apply. However, bloated typeclasses
seems
to be bad design. C++ concepts are never bloated like this nor are haskell
typeclasses.

> I agree that `bind` isn't a good choice. I'll think of something, but
> `apply`
> and `compute` are out of question because Monads are not computations;
> that's
> just one metaphor.
> 
> 
> > Also, I think it would be better to call the `Monad` concept,
> `Computation`
> > or something like that, since monad doesn't mean anything at all outside 
> > the FP community.
> 
> First, I find Computation to be too reductive. Second, I don't want to
> rename
> a concept that's well known in FP and unknown in C++ to something else
> that's
> unknown in C++; I'd rather keep the well known FP word. Anyway, the day
> where
> all C++ programmers will know Monads is coming, but DQMOT. 

The definition of a monad from wikipedia is a structure that represents
computations defined as sequences of steps, so calling it `Computation`
makes
sense. Also the definition and the name is simple and clear to a lot of
non-FP
programmers. In contrast, calling it a monad and then defining it as an
applicative with the ability to flatten values that were lifted more than
once, is pretty meaningless to most C++ programmers. Monads as computations
is
just one metaphor, but it is the metaphor most familiar to C++ programmers.
Or
do you think there is a better metaphor for C++ programmers?

Here are some other thoughts after looking at it more:

- A lot of functions can be implemented with just `Iterable`, such as fmap,
  concat, cons, filter, init, take, take_while, take_until, etc. Or am I
  missing something?

- The parameters to the functions are backwards to what most C++ programmers
  are used to, which will be the source of unendless confusion. I assume
they
  are in this order because of its usefulness for curring inside
applicatives.
  Perhaps instead, you could have another function adapter that rotates the
  first parameter to the last parameter, and then still keep the C++
  convention of putting the sequence first.

- It's important to note that the `decltype_` function will only work for
  constexpr-friendly types.

- There seems to be a lot of copying by value, where it should use perfect
  forwarding. Has this been tested with non-copyable types and expensive to
  copy types as well?

--
View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-tp4665622p4665912.html
Sent from the Boost - Dev mailing list archive at Nabble.com.