Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-07-30 12:10:23
> That is slightly inacurate. I don't use iterators because other
> provide much more expressiveness and are much more general than iterators.
> Since performance is not an argument in favor of iterators in our case (as
> you rightly observe), they are not used. The #1 reason is expressiveness.
I understand how it is simpler to define sequences using `head`/`tail`, but
how is it more expressive?
> Hana is fundamentally functional, it uses rather abstract concepts and
> what makes it so powerful. Truth is, "Sequence" and "Container" concepts
> easy to understand but they only get you so far; they are not general
> to be used as building blocks.
I believe Alex Stepanov would like to have a word with you ;)
> I did try using both.
What limitiation did you run into seperating "Sequences" and "Algorithms"?
> > Also, most C++ programmers are used to seeing libraries divided into
> > containers and algorithms, whereas Boost.Hana seemed to be built around
> > haskell-like interfaces.
> Hana is actually built around concepts (type classes) and models of those
> concepts (data types). Apart from the names, which I agree could have been
> chosen differently, it's the same "design paradigm" as usual generic C++
Yet it uses a lot of foreign functional concepts. Despite what google says,
boost libraries are built around mostly C++-like 'interfaces'. I don't think
its bad to introduce some functional-interfaces, but I know in the past
libraies that libraries that were very functional were rejected from boost,
because many people didn't grasp the purpose of them. So introducing a lot
functional interfaces on the surface of a library can hinder its adoption.
Also, the uses concepts that have a default methods are not very common. In
general, a C++ concept defines a core set of functionality that can be used
extend a library.
> > Ideally, it would be nice to start with simple concepts, such as
> > and then have algorithms built on top of that.
> I'm not sure what you mean by that. Do you mean change the structure of
> type classes, or how they are introduced?
Yes, change the structure of the typeclasses. For example, `Iterable` has
`for_each` included(which is defaulted). However, you could seperate
`for_each` out as an algorithm that requires an `Iterable`. Then have a
seperate mechanism to override the algorithms, such as for varidiac
template<template<class...> class Sequence, class... Ts>
struct algorithm<for_each, Sequence<Ts...>>
static void call(Sequence<Ts...> & s, F f)
The same can be done for the accessors as well in the `Iterable` typeclass.
> There are two things here. First, the decision not to split the library
> a thousand headers was considered a feature, because it meant that you did
> not need to include countless headers to get some functionality. Since the
> library is very lightweight, it does not cause a compile-time performance
> problem to include the whole list.hpp header.
Even so, in your implementation of list.hpp, it may not be performance hit
include it together, but perhaps as a user, I could be adapting a type where
each of those methods are heavyweight, so I would want to seperate them out
into seperate headers.
> Second, I agree that the List type class is heavy, but that's because it's
> more like a data type really. The only reason I made it a type class is
> because I wanted to give `fusion::vector`, `std::tuple` and friends the
> methods as `hana::list`, for free. The laws of List force every instance
> be isomorphic to `hana::list`, so there is no reason why you would want to
> instantiate it.
Just as non-member functions are preferred when they only access public
members, I believe this same advice can be applied here. Each method that
a default implementation could be made as a seperate function(which could be
designed to be overloaded as well).
-- View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-tp4665622p4665818.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk