Brian Schrom writes:

[...]

I'm a FP novice and thoroughly enjoyed reading through the top level documentation. It seemed very approachable and well written. I was able to at least glimpse at what the intention was, even not being able to fully comprehend it in a first reading. I'm anxious to see where this goes and to get more familiar with the paradigm as a result. Thanks for sharing your work and contributions.

Thank you for your feedback. If you ever find something to be unclear, badly explained or just hard to understand in the documentation, please create a GitHub issue and I will try to make the situation better. Being understandable by non-FP people is important for Hana because of the C++ audience it is aimed at. Louis

Steven Watanabe writes:

AMDG

I've just glanced over the main page of the documentation and I had a few comments:

- _tuple Historically names beginning with _ are used for placeholders. i.e. in Boost.Bind/Lambda/Phoenix/Parameter. Is there a good reason not to call it tuple?

It is because of other constructs in Hana like `tuple_t` which are variable templates and whose type is not specified. I have not found a good naming convention for variable templates and types yet. I'll sketch out the current state of affairs, and perhaps someone can suggest a convention that would work well. Hana currently proposes the following: _tuple : The type of a tuple containing objects of type T... make_tuple(x...): Create a tuple of type _tuple...> tuple(x...): Currently equivalent to make_tuple(x...), but deprecated because I'd like to use it in place of _tuple. Tuple: The generalized data type of tuples. tuple_t: A variable template returning a tuple containing types. This object has an _unspecified type_, but its data type is Tuple. In other words, this behaves as a tuple, but it does not have the same representation. It's for optimization purposes. Where it becomes really tricky is that the type of this object is dependent, so it can't be used for pattern matching. However, it is currently specified as inheriting the _tuple_t type, which allows one to pattern match in overloaded functions. tuple_c: A variable template returning a tuple containing integral constants. This returns an object of type _tuple_c, which is not the same as _tuple. It behaves like a tuple, but has a different representation. For optimization purposes too. Other components follow similar conventions. For example, _range: The type of a range containing IntegralConstants of data type T spanning the given interval. Range: The generalized data type of _range<...>. make_range(from, to): Create a _range. range(from, to): Equivalent to make_range(from, to), but deprecated because I'd like it to replace `_range`. range_c: Shortcut to create a range of IntegralConstants. This is similar to vector_c in the MPL. And so it goes. Writing this, perhaps it would make sense to simply replace `_range` by `range`, `_tuple` by `tuple` and etc.

- // BOOST_HANA_RUNTIME_CHECK is equivalent to assert In that case, what is the point of using it instead of assert? I think you should probably avoid using these constructs in the user documentation of other parts of the library. It's just a distraction, so it's better to rely on standard components, which users probably already understand.

The problem is that `assert` is not define when NDEBUG is defined, but I want my tests to fire up all the time. Since these examples are Doxygen'd out of actual source files, the macros end up in the documentation. Basically, If I could redefine `assert` to be `BOOST_HANA_RUNTIME_CHECK` in those test files, I'd be really happy. Would it be against good software craftsmanship to write ... include all you need ... #ifndef assert # define assert(...) BOOST_HANA_RUNTIME_CHECK(__VA_ARGS__) #endif

- Is there a reason for using length instead of size, which would be more idiomatic in C++?

Oversight caused by personal preference. I guess I should change that.

- Amphibian algorithms!!!??? Okay, I guess the name is kind of clever. I can't say that I really like it, though.

If you have anything better to propose, I'm all ears.

- foldl/foldr. I really hate these names. I'd prefer fold/reverse_fold, but even fold_left/fold_right would be better.

I personnally hate reverse_fold, since I don't see how it is a "reverse" fold. It's just a fold with different _associativity_ properties. As for fold_right and fold_left, I guess it comes down to personal preference. I opened a "poll" on GitHub to settle this. See [1].

- count is the equivalent of std::count_if, not std::count. - find/lookup should be find_if/find

You're right. It's sometimes hard to set aside personal preferences for the greater good, but I'll do it :-).

- In general I would expect any algorithm that takes a single element for comparison to have both f and f_if forms.

It is possible that a structure can do lookup by equality but not by any predicate, so it wouldn't be able to provide both. But do you have an example in mind of a place where there's an *_if variant missing in Hana? It would almost surely be an oversight.

- sort(predicate): shouldn't this be sort(sequence)?

Typo; thanks for reporting. Louis [1]: https://github.com/ldionne/hana/issues/18

AMDG On 03/05/2015 12:02 PM, Louis Dionne wrote:

Steven Watanabe writes:

...

I've just glanced over the main page of the documentation and I had a few comments:

- _tuple Historically names beginning with _ are used for placeholders. i.e. in Boost.Bind/Lambda/Phoenix/Parameter. Is there a good reason not to call it tuple?

It is because of other constructs in Hana like `tuple_t` which are variable templates and whose type is not specified. I have not found a good naming convention for variable templates and types yet. I'll sketch out the current state of affairs, and perhaps someone can suggest a convention that would work well.

I see. You have too many similar names. I'm not fond of it, but I can't think of anything better off the top of my head.

...

- // BOOST_HANA_RUNTIME_CHECK is equivalent to assert In that case, what is the point of using it instead of assert? <snip>

The problem is that `assert` is not define when NDEBUG is defined, but I want my tests to fire up all the time. Since these examples are Doxygen'd out of actual source files, the macros end up in the documentation. Basically, If I could redefine `assert` to be `BOOST_HANA_RUNTIME_CHECK` in those test files, I'd be really happy. Would it be against good software craftsmanship to write

... include all you need ...

#ifndef assert # define assert(...) BOOST_HANA_RUNTIME_CHECK(__VA_ARGS__) #endif

It won't work. assert is still defined with NDEBUG. It's just defined to do nothing. Personally, I'd just use assert and make sure that NDEBUG is not defined. It isn't really important though, and I don't think it's a good idea to put ugly workarounds in examples, since the whole point of examples is to be relatively easy to understand.

...

- foldl/foldr. I really hate these names. I'd prefer fold/reverse_fold, but even fold_left/fold_right would be better.

I personally hate reverse_fold, since I don't see how it is a "reverse" fold. It's just a fold with different _associativity_ properties. As for fold_right and fold_left, I guess it comes down to personal preference. I opened a "poll" on GitHub to settle this. See [1].

I see. I think of the algorithm as starting with the state and merging in successive elements. foldl starts at the beginning of the sequence and works it way to the end, while foldr starts at the end and works its way to the beginning. It sounds like the difference is that you're thinking of fold as a single mathematical operation, instead.

...

- count is the equivalent of std::count_if, not std::count. - find/lookup should be find_if/find

You're right. It's sometimes hard to set aside personal preferences for the greater good, but I'll do it :-).

I wouldn't really object if you only provided predicate forms. The problem is that some algorithms have only a predicate form, while others have both predicate and value forms. If you do provide both, than you need a consistent naming convention, and while f/f_if aren't the greatest names ever, they will be familar to most C++ programmers.

...

- In general I would expect any algorithm that takes a single element for comparison to have both f and f_if forms.

It is possible that a structure can do lookup by equality but not by any predicate, so it wouldn't be able to provide both.

That seems like a serious limitation. Logically find(s, x) should be equivalent to find(s, [](auto y) { return x == y } ) Also, your Searchable seems to be based on predicates, so I'm not sure how such a structure would work with your library.

But do you have an example in mind of a place where there's an *_if variant missing in Hana? It would almost surely be an oversight.

replace only seems to have a predicate form. In Christ, Steven Watanabe

On 5 Mar 2015 at 19:02, Louis Dionne wrote:

...

- // BOOST_HANA_RUNTIME_CHECK is equivalent to assert In that case, what is the point of using it instead of assert? I think you should probably avoid using these constructs in the user documentation of other parts of the library. It's just a distraction, so it's better to rely on standard components, which users probably already understand.

The problem is that `assert` is not define when NDEBUG is defined, but I want my tests to fire up all the time. Since these examples are Doxygen'd out of actual source files, the macros end up in the documentation. Basically, If I could redefine `assert` to be `BOOST_HANA_RUNTIME_CHECK` in those test files, I'd be really happy. Would it be against good software craftsmanship to write

... include all you need ...

#ifndef assert # define assert(...) BOOST_HANA_RUNTIME_CHECK(__VA_ARGS__) #endif

I'd suggest an alternative course: these are "current state is impossible" assertions right? In which case fatal application exit is the only valid outcome, plus you want them always there even in optimised builds, and ideally you want some sort of useful error message. You may find my BOOST_AFIO_THROW_FATAL(x) macro of use here https://github.com/BoostGSoC13/boost.afio/blob/master/include/boost/af io/detail/Utility.hpp#L135. It tries to throw an exception in a noexcept function first, and if that succeeds (e.g. MSVC) then it calls std::terminate. The print_fatal_exception_to_stderr() function dumps a stack trace to stderr on supported platforms, just to be very, very sure you get something debuggable. Most of AFIO's testing happens on a Jenkins CI to catch the really rare non-repeatable bugs, the ones not findable on your dev workstation, so having useful telemetry as to what went wrong is invaluable. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 6 Mar 2015 at 1:11, Louis Dionne wrote:

...

I'd suggest an alternative course: these are "current state is impossible" assertions right? In which case fatal application exit is the only valid outcome, plus you want them always there even in optimised builds, and ideally you want some sort of useful error message.

The *_CHECK macros in Hana are just meant to be used for unit testing. They should be enabled in all build configurations so I can test both the Debug and Release modes. Currently, BOOST_HANA_RUNTIME_CHECK(expr) is defined (roughly) as

if (!expr) { std::cerr << "some useful error message"; std::abort(); }

Of course it is less naive PP-wise, but that's the gist of it.

Ah, then I'd urge you to use BOOST_CHECK/BOOST_REQUIRE which will spit out the results of all your tests into an XML file that Jenkins CI can display on a pretty graph. Then you can get Hana being nightly soak tested for compilation time/memory consumption regressions etc. You don't need Boost.Test necessarily for this, yet to be renamed BindLib has a threadsafe CATCH fork wrapped into Boost Test emulation macros. CATCH is totally header only, my threadsafe fork you can fetch as one giant single standalone include file at: https://github.com/ned14/Catch-ThreadSafe/blob/develop/single_include/ catch.hpp Just drop that into your git repo. No dependencies needed. If you want a preformed set of Boost test macros which thunk into threadsafe CATCH, that can be found at: https://github.com/ned14/Boost.BindLib/blob/master/include/boost/test/ unit_test.hpp Which is also header only, I even use some undefined behaviour to avoid you having to bother with with defining your own main(). Oh, and CATCH prints your unit testing results in pretty colours to the console. Plus you can run unit test filters, useful when you want to narrow into a very small part of the test suite. Much nicer than std:cerr :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

AMDG On 03/05/2015 01:15 PM, Matt Calabrese wrote:

<snip>What this implies is that simply by writing pointer == tuple_t, the effect is that the type "Car" is implicitly instantiated at this point (if it were template instantiation), because the compiler needs to see if there are base classes in order to properly form the set of associated namespaces!

In this particular example it might not be too apparent why this is so bad, but in the general case, instantiating such types that are involved can cause a number of serious issues: 1) Perhaps the most obvious is that instantiation can potentially fail (and therefore cause a compile error even though it doesn't look like the type would be used).

I'm glad you brought this up. This problem is not academic. I've seen real bugs reported against at least one Boost library because of something like this.

2) They can cause considerable compile-time overhead for a template definition's instantiation that otherwise might not be used. 3) Worst case, but probably the least likely. It can compile but produce strange results in the program in a very subtle way, not even necessarily directly at this point in code, due to the type being instantiated "prematurely" with respect to what the user may have expected. This can can cause problems, for instance, if certain types are still incomplete at this point in the translation unit, or if important functions/overloads have not yet been declared, etc. Because of memoization, at the point that the user thinks they are first instantiating the template, they will get an instantiation that they likely did not expect.

In Christ, Steven Watanabe

On Thu, Mar 5, 2015 at 12:56 PM, Louis Dionne wrote:

Yes, this is already taken care of and no unfortunate instantiations will take place.

Awesome!!!

The downside is that `decltype(tuple_t)` is an unspecified dependent type that only _inherits_ `_tuple`.

I'm playing with fire, I know :-). I read the process of ADL very carefully when I thought about this, but it is also possible that I'm exploiting a Clang bug. What do you think?

Hmm, I think that really might be relying on a clang bug, but I don't have the standard in front of me right now. From my understanding, if you inherit from _tuple, then "T..." again needs to be considered for the list of associated namespaces. -- -Matt Calabrese

On Thu, Mar 5, 2015 at 1:28 PM, Louis Dionne wrote:

I also double-checked the standard (ok, cppreference.org [2] to be fair). For what follows, let's denote by Hidden the type `_tuple_t::_` as can be seen in the gist. Here's my reading of it (the standardese is indented):

Cool, I just looked it up in the standard as well, and I think you're right. I thought the associated namespaces of the bases were considered, but it's only the namespaces of the associated base classes that are considered. -- -Matt Calabrese

Jason Roehm writes:

[...]

I can verify that the linked gist compiles and runs successfully on the latest Intel C++ compiler.

[jasonr <at> dirac:~/Downloads]$ icpc --version icpc (ICC) 15.0.1 20141022 Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

Awesome! Thank you very much! Louis

Edward Diener writes:

...

[...]

In the Quick Start:

...

auto stuff = make_tuple(Person{"Louis"}, Car{"Toyota"}, City{"Quebec"}); Notice how the auto keyword is used when defining xs;...

It should be:

...

Notice how the auto keyword is used when defining 'stuff';...

Thank you, fixed! Louis

Vicente J. Botet Escriba writes:

[...]

I appreciate what has been done already to improve the tutorial. Next follows some comments about the design.

DataTypes and TypeClasses ---------------------- I appreciate what has been done already. I have some trouble with the "datatype" use. If I understand it correctly, the type you map to a "type class" is not the type itself but its datatype (which can be the same).

That is correct. Hana also calls them generalized types, because they are like types, but ones that don't care about the actual representation (memory layout) of the objects. In a sense, a data type is like a C++ concept, but one that would only be modeled by a couple of types that would be exactly the same up to representation differences.

In Haskell, type classes can be universally quantified or not. E.g. the "type class" Eq is not universally quantified

[...]

That means that the instance mapping for Eq is from types (*) and the instance mapping for Functor is for type constructors having one parameter (* ->*).

[...]

I don't see this nuance in your library. [...]

This is because this nuance is _voluntarily_ left aside. More generally, the design choice I made was to leave parametric data types to the documentation level only, as is documented in the section about generalized data types[1]. As I already said on this list during the last informal review, what I make is a tradeoff between mathematical correctness and usability of the library. While Hana provides structures that satisfy the laws rigorously, I want users to be able to use those structures in a quick and dirty way as a mean of being more productive when needed. For example, I would not object to someone writing [pseudocode]: auto to_string = [](auto x) { /* convert x to a std::string */ }; auto xs = hana::make_tuple(1, 2.2, "abc"); auto ys = hana::transform(xs, to_string); Since `1`, `2.2` and `"abc"` do not share a common data type and the signature of `transform` is (for a Functor F) transform : F(T) x (T -> U) -> F(U) , the above should normally be ill-formed. However, the library makes such usage possible because I kept in mind that we're working in a "dirty" heterogeneously-typed context. Bottom line: Concepts in Hana are rigorously specified and coherent internally. You are free to bypass them when you need to, because, while it would always be possible to do it, it would be painful to always justify how operations are mathematically correct [2].

Compile-time error reporting --------------------

I would expect that the library provide some king of "TypeClass" check use (As Eric's Range library does with Concepts) so that the compile time errors are more explicit.

Doing this for all parameters of all functions is intractable due to the heterogeneous context, but basic support could be added easily. I'm promoting this on my todo list.

Unnamed data types ----------------- I'm missing, between other, the concrete types _either and _maybe<T>, as we have _pair. How the user can declare a structure having data members with these data types?

You can't if you don't know beforehand whether it's going to be a `just` or a `nothing`. Hence, it is useless to create such a data member _explicitly_. The reason is that whether a Maybe is a `just` or a `nothing` is encoded in its type, so you have to know it if you want to _explicitly_ declare such a data member. That's the downside. The upside is that it allows you to interact with heterogeneous objects, which was the initial goal. There's an example of how this can be used to encode SFINAE-failures at [3].

About a pure type meta programming sub-library Hana/Meta ----------------------------------------------------

While I agree that it is good to be able to define the algorithms only once for types and values, I find the syntax cumbersome when the user wants only to work at the meta-programming level.

I think you overestimate how often you actually need to do computations on types. We were just accustomed by the MPL to write everything with raw types, but this is not the only way to do it. The only times we actually need to manipulate types is when we use , which does not represent the largest part of metaprogramming in my experience.

I wonder if the library shouldn't contain a sublibrary Hana/Meta that defines in a meta namespace all the algorithms/types that work directly on types and integral constants.

Instead of defining a hana::tuple_t, I suggest to define it in meta::tuple that works only with types and a meta::transform that works only on types.

This will allow to write ([1])

static_assert( meta::transform, std::add_pointer>{} == meta::tuple{} , "");

instead of

static_assert( hana::transform(hana::tuple_t, hana::metafunctionstd::add_pointer) == hana::tuple_t , "");

The definition of meta::transform will just do the steps 2 and 3 of the process you describe:

1. Wrap the types with |type<...>| so they become values 2. Apply whatever type transformation |F| by using |metafunction<F>| 3. Unwrap the result with |decltype(...)::type|

[...]

First of all, the first alternative will almost surely need to look more like: static_assert( meta::transform, meta::quotestd::add_pointer>{} == meta::tuple{} , ""); Notice meta::quote. Now, if you compare with static_assert( hana::transform(hana::tuple_t, hana::metafunctionstd::add_pointer) == hana::tuple_t , ""); , I think you have to admit the difference is tiny. Hana also provides integration with , which means that you can actually write: static_assert( hana::transform(hana::tuple_t, hana::traits::add_pointer) == hana::tuple_t , ""); The difference is that with Hana, you would then need to use `decltype(...)::type` to get back the actual type. Again, my answer is that this is only required at some thin boundaries where you actually need the types. HOWEVER, there seem to be some demand for this from the community. I'll be very honest and direct with you and everyone else on this list: if this addition can make people feel more at home because it resembles the MPL, and if in turn that eases the process of making Hana part of Boost, then I could do it. However, on my part, I would find that it encourages people to leverage only the _tiny_ part of Hana that deals with type-level metaprogramming, and hence reduce what can be done with it to a small portion of its full power. Also, if I could be shown examples in which the 3-step process described above is really painful, and if those examples turned out not to simply be non-idiomatic Hana, I would add those facilities by the end of the day. On a more serious note, and because this issue has to be closed once and for all, I created a poll at [4] to resolve whether such facilities should be added. It is not a guarantee that I'll do it if people want it, but I'd like to have an idea of how badly people want it.

An additional advantage of having this Meta library is that it can be defined using just a C++11 compiler, as it is done in Eric's Meta library.

I understand they _could_ be implemented in C++11 only, but concretely they would use Hana as a backend and so they would need C++14. I would not reimplement those operations from scratch. Thanks for your comments and questions that never fail to challenge me, Vicente. Regards, Louis [1]: http://ldionne.github.io/hana/#tutorial-hetero [2]: For the example I gave, it would be possible, for example, to say that we're creating a Tuple of things that can be converted to a `std::string`. Let's call this data type `Stringizable`. Then, the data type of the tuple would be `Tuple(Stringizable)`, and the signature of transform that we would be using is transform : F(Stringizable) x (Stringizable -> std::string) -> F(std::string) Until I have a deeper formal understanding of the way this process of "intersecting the concepts of the objects in a sequence" works, which I'm working on as my bachelor's thesis, I'd rather keep Hana's concepts free of higher-order data types. Even if/when I'll have a deeper formal understanding, I would likely need language support to make this applicable. [3]: http://goo.gl/MgUIpl [4]: https://github.com/ldionne/hana/issues/19

Vicente J. Botet Escriba writes:

Le 07/03/15 17:38, Louis Dionne a écrit :

...

Vicente J. Botet Escriba writes:

[...]

I see much more you datatype as a tag.

That's exactly what they are. However, Fusion and MPL did not see tags for what they are actually: a powerful way of lifting the type system one level higher up to make representation differences unimportant. Fusion and MPL only saw tags as part of their dispatching system. I think it's mostly a philosophical difference at this point.

Do you have an equivalence in Haskell to your datatype/generalized type?

No, but shooting from the hip you could approximate them with type classes. For example, the Tuple data type could be implemented as -- The different actual representations for tuples data Tuple0 = Tuple0 data Tuple1 a = Tuple1 a data Tuple2 a b = Tuple2 a b data Tuple3 a b c = Tuple3 a b c -- etc... -- The Tuple generalized type representing all those guys class Tuple t where len :: t -> Int instance Tuple Tuple0 where len _ = 0 instance Tuple (Tuple1 a) where len _ = 1 instance Tuple (Tuple2 a b) where len _ = 2 instance Tuple (Tuple3 a b c) where len _ = 3 -- etc... Admittedly, the above is missing something fundamental if we want to implement other functions like `head`, but that reaches the limit of my Haskell-fu. I think looking at Haskell's type families [1] might provide more insight.

...

[...]

This is because this nuance is _voluntarily_ left aside. More generally, the design choice I made was to leave parametric data types to the documentation level only, as is documented in the section about generalized data types[1].

I can understand that you want to let the constraint as comments or documentation as the Standard library does. However I expect that implementations do a check at compile time when possible.

Strictly speaking, a "check" is done at compile-time, in that you'll get a nasty compiler error if the types don't match. Nothing is "erased" and left to deal with by some runtime, if that's what you meant. Of course, in practice, Hana will static_assert in some places to make these errors more explicit.

...

As I already said on this list during the last informal review, what I make is a tradeoff between mathematical correctness and usability of the library. While Hana provides structures that satisfy the laws rigorously, I want users to be able to use those structures in a quick and dirty way as a mean of being more productive when needed. For example, I would not object to someone writing [pseudocode]:

auto to_string = [](auto x) { /* convert x to a std::string */ }; auto xs = hana::make_tuple(1, 2.2, "abc"); auto ys = hana::transform(xs, to_string);

Since `1`, `2.2` and `"abc"` do not share a common data type and the signature of `transform` is (for a Functor F)

transform : F(T) x (T -> U) -> F(U)

, the above should normally be ill-formed. However, the library makes such usage possible because I kept in mind that we're working in a "dirty" heterogeneously-typed context. Bottom line:

I don't think heterogeneous types are dirty. We need just a different type of function (Overloaded) to transform them.

if you have an heterogeneous type as pair for example, the mathematical transform function should

transform : pair(T,U) x (T -> R) x (U -> S) -> pair(R, S)

As C++ has overloaded functions we don't need to pass two functions, but just an overloaded function.

That's an interesting point of view. However, with this approach, you can't say that Pair is a Functor. It instead becomes a BiFunctor [2]. Furthermore, let's say you have a pair(T, T). transform is then transform : pair(T, T) x (T -> R) x (T -> S) -> pair(R, S) transform should hence still receive two functions, regardless of the fact that we could provide a single overloaded function. Let me now use a tuple instead of a pair as an example because it sticks more closely to what happens in Hana (Pair is not a Functor in Hana). transform then becomes: transform : Tuple(T1, ..., Tn) x (T1 -> R1) x ... x (Tn -> Rn) -> Tuple(R1, ..., Rn) First, if you use this approach, you can't say that Tuple is a Functor. It has to be a N-Functor, which is the N-argument equivalent to the BiFunctor. Furthermore, you have to provide N different functions to be able to transform it. So for example, when transforming a tuple(int, int, int), you would have to say transform(tuple(1, 2, 3), [](int i) { return i + 1; }, [](int i) { return i + 1; }, [](int i) { return i + 1; } ) That's not "heterogeneous" programming; it's just an equivalent way of writing r1 = f1(t1) r2 = f2(t2) ... rn = fn(tn) where `tk` are the elements of a tuple, and `fk` are the functions mapped on it by the N-Functor's `transform`. What we actually want is r1 = f(t1) r2 = f(t2) ... rn = f(tn) where `f` is defined as f : (intersection of the data types of the tuple's elements) -> (some other type) In other words, `f` is a function whose domain is "the set of all objects with which I can do X". If there are objects in the tuple that don't support "X", then the program is ill-formed. Concepts will put us much closer to this. The principle behind Hana's generalized types is really that we "lift" the types of the objects and then consider objects up-to-different-representations. I also think it can be seen as a quotient of the set of all types by the equivalence relation T ~ U if and only if T and U model exactly the same concepts in exactly the same way Concretely, the mathematical universe we're working with is not only a set; it's actually the C++ category where objects are Types and morphisms are functions. Hence, that "quotient" would have to also take morphisms into account. But I'm reaching the end of my math-fu now.

[...]

How the fact to have either and maybe<A> makes it more dificult to interact with heterogeneous objects?

Let's try to implement a type _maybe<A>: template <typename A> struct _maybe { struct empty { }; union { A a; empty e; } val; bool is_nothing; constexpr _maybe() : val{empty{}}, is_nothing{true} { } constexpr _maybe(A a) : val{a}, is_nothing{false} { } }; Now, let's try to implement, for example, the `maybe` function, which has signature maybe :: B x (A -> B) x _maybe<A> -> B. Remember that those A's and B's are actually generalized types, not usual C++ types (we're working with heterogeneous stuff): template constexpr auto maybe(Default def, F f, M m) { return m.is_nothing ? def : f(m.val.a); } Seems legit? This works: maybe(1, [](int i) { return i + 1; }, _maybe<int>{1}); But this does not, even though std::tuple<> and std::tuple<int> have the same generalized type: maybe( std::tuple<>{}, [](int i) { return std::make_tuple(i); }, _maybe<int>{1} ); It fails with error: incompatible operand types ('tuple<(no argument)>' and 'tuple<int>') return m.is_nothing ? def : f(m.val.a); ^ ~~~ ~~~~~~~~~~ m.is_nothing is not a constant expression inside the function. If it was, we could use `bool_` to use overloading to pick which branch we're executing instead of doing it at runtime, like we do right now. This is explained in the section on the limitations of constexpr [3].

...

[...]

Notice meta::quote.

I wonder if the meta::transform couldn't take care of quote.

If it takes care of quote, then we need to always pass templates to higher order algorithms. Basically, that would be like accepting metafunctions instead of metafunction classes in the MPL interface. There are good reasons not to do that.

[...]

My point was more on how the library is checking the fist argument of Transform is a Functor and that the second argument is a "function" from the Functor's underlying type T to another type U.

transform : Functor<T> x (T -> U) -> Functor(U)

If the implementation declares transform as

auto transform = [] (auto F, auto Fun)

Couldn't the the library check that the arguments passed in F and Fun respect the requirements?

Yes, but that would require `Fun` stating that it is a function from data type T to data type U, which is impractical. In particular it means that this: transform(make_tuple(1, 2, 3), [](int i) { return i + 1; }); would not work. Instead one would need to write transform(make_tuple(1, 2, 3), hana::function([](int i) { return i + 1; })); Then, say you have transform(make_tuple(1, std::string{"abc"}, my_class{}), hana::function([](auto x) { ... })); The way I see it, it's just not convenient. Doing it would definitely force us to be mathematically correct though. Instead, I aim to catch most programming errors by checking that F is a Functor (which is easy). If you send in a random function, then the compiler will tell you where you're wrong, but Hana won't. Regards, Louis [1]: http://goo.gl/fY8pcw [2]: http://goo.gl/Iy4FKu [3]: http://ldionne.github.io/hana/#tutorial-constexpr

Vicente J. Botet Escriba writes:

Le 07/03/15 21:00, Louis Dionne a écrit :

...

Vicente J. Botet Escriba writes:

...

Le 07/03/15 17:38, Louis Dionne a écrit :

...

Vicente J. Botet Escriba writes: [...]

Do you have an equivalence in Haskell to your datatype/generalized type? No, but shooting from the hip you could approximate them with type classes.

A type class that is instantiated with another type class?

Like I said, I don't know Haskell well enough to tell whether there's a direct mapping between data types in Hana and something else in Haskell. Is there an equivalent to Fusion/MPL tags in Haskell?

[...]

Does it means that you are associating a "principal" type class (obtained by the function datatype) to a data type, that is used to instantiate the other type classes?

I was just using the Tuple type class as a hack to "group" the different TupleN representations under the same umbrella. Again, I'm not a Haskell wizard and there might be a clean way to do it.

...

...

[...] if you have an heterogeneous type as pair for example, the mathematical transform function should

transform : pair(T,U) x (T -> R) x (U -> S) -> pair(R, S)

As C++ has overloaded functions we don't need to pass two functions, but just an overloaded function. That's an interesting point of view. However, with this approach, you can't say that Pair is a Functor. It instead becomes a BiFunctor [2].

Right. A Functor has only one type parameter. In Haskell you can not overload functions so that the functions must be named differently. But in C++ we can use the same name, so we could have a transform : BiFunctor x BiCallable -> BiFunctor.

IIUC, BiCallable basically represents two functions with different domains stitched into a single function via C++ overloading, right? Then, I say we don't want that because it still represents two different functions with two different domains, instead of a single function with the proper domain.

...

Furthermore, let's say you have a pair(T, T). transform is then

transform : pair(T, T) x (T -> R) x (T -> S) -> pair(R, S)

transform should hence still receive two functions, regardless of the fact that we could provide a single overloaded function.

pair(T, T) can be seen as an instance of Functor as list(T) does.

We need an alias

template <class T> using pairT = pair;

See below.

...

Let me now use a tuple instead of a pair as an example because it sticks more closely to what happens in Hana (Pair is not a Functor in Hana). tuple shouldn't be a Functor neither. transform then becomes:

transform : Tuple(T1, ..., Tn) x (T1 -> R1) x ... x (Tn -> Rn) -> Tuple(R1, ..., Rn)

First, if you use this approach, you can't say that Tuple is a Functor. It has to be a N-Functor, which is the N-argument equivalent to the BiFunctor. Furthermore, you have to provide N different functions to be able to transform it. So for example, when transforming a tuple(int, int, int), you would have to say

transform(tuple(1, 2, 3), [](int i) { return i + 1; }, [](int i) { return i + 1; }, [](int i) { return i + 1; } )

As pair, and list<T> tuple can be seen as an instance of a Functor. But not its heterogeneous variants.

Fine, but what about tuple? Clearly, transform should receive three different functions: transform : tuple x (T -> A) x (U -> B) x (T -> C) -> tuple And hence we still have a 3-Functor (for w/e that means). I think I'm starting to understand where our views diverge: You keep on trying to see heterogeneous data structures like tuples as product types, which they are at the most basic level. I lift the type-system one level higher up and see tuples as a fixed-length arrays of objects with the same "type" (generalized type). This approach has some advantages, like being able to look at objects of the Type data type as objects of the same "type". Those objects all have a common interface, which corresponds to the .

...

That's not "heterogeneous" programming; it's just an equivalent way of writing

r1 = f1(t1) r2 = f2(t2) ... rn = fn(tn)

where `tk` are the elements of a tuple, and `fk` are the functions mapped on it by the N-Functor's `transform`. What we actually want is

r1 = f(t1) r2 = f(t2) ... rn = f(tn)

where `f` is defined as

f : (intersection of the data types of the tuple's elements) -> (some other type) I'm sure doing such kind of transformations is useful. However the semantic doesn't match to the transform(fmap) function associated to the Functor I know.

It's because Hana does not use the Functor _you_ know. It's pretty much a work in progress, but you might be interested in taking a look at my thesis [1]. I show how we can categorify Hana, and I'm about to explain how Functors materialize themselves. It is in essence exactly the same thing as what happens with the Hask category, except that you replace "type" by "generalized type".

...

In other words, `f` is a function whose domain is "the set of all objects with which I can do X". If there are objects in the tuple that don't support "X", then the program is ill-formed. Concepts will put us much closer to this.

Do you mean C++17/20 Concepts? Couldn't "type classes" help here?

Yes, C++ Concepts. I just meant that C++ Concepts would help us put constraints on families of types, without having to fix their representation.

...

...

[...]

How the fact to have either and maybe<A> makes it more dificult to interact with heterogeneous objects? Let's try to implement a type _maybe<A>:

template <typename A> struct _maybe { struct empty { };

union { A a; empty e; } val; bool is_nothing;

constexpr _maybe() : val{empty{}}, is_nothing{true} { } constexpr _maybe(A a) : val{a}, is_nothing{false} { } };

Now, let's try to implement, for example, the `maybe` function, which has signature maybe :: B x (A -> B) x _maybe<A> -> B. Remember that those A's and B's are actually generalized types, not usual C++ types (we're working with heterogeneous stuff):

template constexpr auto maybe(Default def, F f, M m) { return m.is_nothing ? def : f(m.val.a); }

Seems legit? This works:

maybe(1, [](int i) { return i + 1; }, _maybe<int>{1});

But this does not, even though std::tuple<> and std::tuple<int> have the same generalized type:

maybe( std::tuple<>{}, [](int i) { return std::make_tuple(i); }, _maybe<int>{1} );

It fails with

error: incompatible operand types ('tuple<(no argument)>' and 'tuple<int>') return m.is_nothing ? def : f(m.val.a); ^ ~~~ ~~~~~~~~~~

This seems normal to me.

It _is_ normal, but it's not useful in a context of dealing with heterogeneous values, because you can't return objects of different types from that function. What we need is to store the information required to make that branch in the Maybe's type, and then we can return objects of different types from that function, because the conditional is actually implemented as an overload.

Does it mean that classes as experimental::optional<T> couldn't be seen as an instance of Hana Functor type class?

Yes, it can be a Functor. Just like std::vector is a Hana Functor (I added this recently). However, some types that are fundamentally useful at runtime can't model some concepts in Hana. For example, the current library requires the is_empty method (from Iterable) to return an IntegralConsant. For this reason, std::vector can't be made Iterable.

...

m.is_nothing is not a constant expression inside the function. If it was, we could use `bool_` to use overloading to pick which branch we're executing instead of doing it at runtime, like we do right now. This is explained in the section on the limitations of constexpr [3].

Does it means that your data types Maybe and Either are usable only as meta-programming tools? I don't see where could I use them at run-time.

You're right, they are mostly useless at runtime, just like boost::optional and boost::variant are completely useless at compile-time. That's exactly the point; Hana is a _metaprogramming_ library. Quoting from Maybe's documentation [2]: [...] However, there is an important distinction to make between Maybe and std::optional: just(x) and nothing do not share the same type. Hence, whether a just or a nothing will be returned from a function has to be known at compile-time for the return type to be computable at compile-time. This makes Maybe well suited for static metaprogramming tasks but very poor for anything dynamic.

...

...

[...]

My point was more on how the library is checking the fist argument of Transform is a Functor and that the second argument is a "function" from the Functor's underlying type T to another type U.

transform : Functor<T> x (T -> U) -> Functor(U)

If the implementation declares transform as

auto transform = [] (auto F, auto Fun)

Couldn't the the library check that the arguments passed in F and Fun respect the requirements? Yes, but that would require `Fun` stating that it is a function from data type T to data type U, which is impractical. In particular it means that this:

transform(make_tuple(1, 2, 3), [](int i) { return i + 1; });

would not work. Instead one would need to write

transform(make_tuple(1, 2, 3), hana::function([](int i) { return i + 1; }));

Then, say you have

transform(make_tuple(1, std::string{"abc"}, my_class{}), hana::function([](auto x) { ... }));

The way I see it, it's just not convenient. Doing it would definitely force us to be mathematically correct though. Instead, I aim to catch most programming errors by checking that F is a Functor (which is easy). If you send in a random function, then the compiler will tell you where you're wrong, but Hana won't.

Maybe it could be a different "transform" function that applies to ProductTypes instead of to Functors. The requirement on Fun could be that Fun is callable with any of the types on the ProductType and that each one of these overloads should have the same result U.

We're basically saying the same thing here. IIUC, your ProductTypes are basically what I call Functors, and saying that Fun is callable with any of the types in the ProductType is just saying they share a set of common concepts, which I try to embody in the concept of data type. There's a small generalization missing from my understanding to bridge the gap between concepts and data types, which I think are the same in the end. See the remark at the end of the section on generalized data types [3].

I think that I need to understand better the scope of the library, is Hana a pure functional programming library or another way to do pure meta-programming or both at the same time, but restricted to the limitations of the intersection?

Like Fusion, Hana is a library that bridges between runtime and compile-time. Basically, you can manipulate sequences with heterogeneous objects in them, but their length has to be known at compile-time. I know there's a way to generalize this so that it works with homogeneous sequences whose size is known at runtime too, but I'm not tackling this right now. Then, type-level computations come for free when you have heterogeneous sequences, but we had just never saw it as clearly as we do now. Hana is not just a "pure functional" library that works at runtime. It's a generalized Boost.Fusion which happens to use concepts from the functional paradigm because it's convenient. Regards, Louis [1]: https://github.com/ldionne/hana-thesis [2]: http://ldionne.github.io/hana/structboost_1_1hana_1_1_maybe.html [3]: http://ldionne.github.io/hana/index.html#tutorial-hetero

Le 07/03/15 19:09, Louis Dionne a écrit :

Louis Dionne writes:

...

Vicente J. Botet Escriba writes:

...

[...]

Compile-time error reporting --------------------

I would expect that the library provide some king of "TypeClass" check use (As Eric's Range library does with Concepts) so that the compile time errors are more explicit. Doing this for all parameters of all functions is intractable due to the heterogeneous context, but basic support could be added easily. I'm promoting this on my todo list. Before I go an change the code, I'd like to make sure I understand your comment properly. Currently, if you use a method with a parameter that does not model the required concept, you'll get an assertion. For example,

hana::head(1);

Produces

[...] error: static_assert failed "no definition of boost::hana::head for the given data types" static_assert(wrong{}, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] note: in instantiation of function template specialization 'boost::hana::head_impl::apply<int>' requested here return head_impl::apply( ^ [...] note: in instantiation of function template specialization 'boost::hana::_head::operator()<int>' requested here hana::head(1);

The check is currently being done in the base case of the tag-dispatched method, `head_impl`. It could also be done higher up, in the "interface method", i.e. `head` itself. For example, here's what I experimented with locally:

hana::head(1);

Produces

[...] error: static_assert failed "hana::head(xs) requires xs to be an Iterable" static_assert(models{}, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] note: in instantiation of function template specialization 'boost::hana::_head::operator()<int>' requested here hana::head(1);

Is this the kind of improvement you were talking about, or was it something else entirely? Regardless, I like this better than my current system and I'll probably do it, but I'd like to make sure I understand your point.

Yes, this is exactly what I would expect. Report errors at the interface level, not the implementation. Vicente

Mathias Gaunard writes:

On 05/03/2015 15:41, Louis Dionne wrote:

...

- Lack of support for mainstream compilers: The library is now almost fully functional with Clang 3.5. A GCC 4.9 port with reduced functionality is also underway on the `redux` branch.

This might sound discouraging, but I consider any library that doesn't work fully with GCC 4.9, Clang 3.5 and MSVC14, which are already bleeding-edge compilers, to not be suitable for real use, and thus not suitable for inclusion into Boost either.

The risk is that this library might never be more than a mere curiosity.

First, Clang 3.5 is now fully supported. Second, you imply that any library which uses variable templates, extended constexpr or other C++14 features that are not well supported yet is not suited for real use. I humbly disagree. On the contrary, I think it is a good occasion to push compiler implementers a bit by making more cutting-edge libraries available to the large public. Then, there will be a bigger incentive to support C++14 properly, but most importantly there will be more bug reports comming in, which triggers improvement. I hope the rest of this community is not feeling the same towards cutting edge libraries. I would suspect that some of the most groundbreaking libraries that are now well accepted and supported by compilers were in Hana's position when they started. Regards, Louis

This might sound discouraging, but I consider any library that doesn't work fully with GCC 4.9, Clang 3.5 and MSVC14, which are already bleeding-edge compilers, to not be suitable for real use

Its important to support more than one compiler, but, I think, it is perfectly acceptable if it doesn't support bug-ridden compilers such as MSVC. Boost is about pushing innovation in C++, and we can't let a compiler that is over half a decade behind the rest of the industry hold back that innovation. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Informal-review-request-tp4672703p46... Sent from the Boost - Dev mailing list archive at Nabble.com.

Eric Niebler writes:

On 3/16/2015 4:43 PM, Louis Dionne wrote: <snip>

...

However, there is a more serious incompatibility stemming from how `reverse_fold` is usually specified and understood: as starting from the end. This causes a problem for infinite data structures, which obviously have no reachable end. Instead, `foldr` is usually specified recursively in a way that makes it possible to right-fold infinite data structures (and it is indeed possible to do so in Haskell and with MPL11). There is no real support for infinite data structures in Hana right now, but simple Concept generalizations which I have been thinking about might make this possible. In summary, I want to make sure I'm not blocking myself if I make the `foldl/foldr` change, but rest assured that I understood very well the people's desire.

I personally don't see a problem with keeping foldr's semantics but changing the name to reverse_fold, if that's what people want.

The problem is that in the infinite case, it's not a "reverse" fold anymore, and hence the name becomes very misleading. For those that might be reading this and wondering what I mean by non-strict folds, here's how `foldr` can be defined recursively: template auto foldr(Sequence xs, State s, F f) { if (is_empty(xs)) return s; else return f(head(xs), foldr(tail(xs), s, f)); } In a strict evaluation context, when the else branch is taken, the foldr(tail(xs), s, f) is always evaluated. However, in a non-strict context, a "thunk" (a deferred computation) is built instead and the else branch looks more like return f(thunk[head(xs)], thunk[foldr(tail(xs), s, f)]); where thunk[expr] is just an `expr` that will be evaluated if its value is required inside of f. So, for example, if `f` is (pseudo) defined as auto f(auto x, auto ignored) { return x; } since `f` never uses the value of its second argument, this argument is never evaluated. So the "else" branch inside the `foldr` becomes: return f(thunk[head(xs)], thunk[foldr(tail(xs), s, f)]); --> return head(xs); and the recursive call to `foldr` is never evaluated. This allows processing infinite lists lazily and writing short-circuiting algorithms such as template bool any_of(Sequence xs, Predicate pred) { return foldr(xs, false, [](auto x, auto y) { return pred(x) || pred(y); }); } implicitly. In the above example, if `pred(x)` returns true for some `x`, then the corresponding `pred(y)` is never evaluated because `||` short-circuits. Because we're in a hypothetical non-strict evaluation world, this causes `y` not to be evaluated at all. However, if you go back to the definition of `foldr` above, the `y` was an expression of the form foldr(tail(xs), s, f) where f is our lambda in the `any_of` algorithm. So basically, we're saying that the recursive call to `foldr` is not evaluated, and hence our `any_of` algorithm short-circuits automatically. So anyway, my point is that seeing right-folds as f(x1, f(x2, f(x3, ...f(xN, state))) is slightly more general than seeing them as starting from the end, because it allows for the case where there's no end. That being said, I'm aware that we're _not_ in Haskell and so it does not really apply to Hana. I'd just like to make sure that I (or someone else) won't find a nice application for infinite data structures in Hana that would make me regret that choice. But writing this, I have the germ of an idea that these lazy folds might be nothing more than a monadic fold with the Lazy Monad, which would resolve the issue. I have to look into this further before I can say anything.

...

7. In a different thread [6], it was suggested that the Logical concept should interact well with Lazy computations. I have begun to investigate possible ways of nicely tying both together, as can be seen at [7], and will try to have something definitive before a formal review.

...

[7] http://ldionne.github.io/2015/03/16/laziness-as-a-comonad

Awesome. I'm really looking forward to reading this.

As it stands, I find the post to be a bit boring because there's no interesting use case at the end. I'm thinking about expanding on how we can compose lazy computations (as Applicatives and Monads), which is really the fun part and also the part that gives us pretty semantics for composing arbitrary lazy computations. Locally, I have prototyped a new `if_` with both lazy and non-lazy semantics which I think will be going into Hana. Anyway, will do if time permits!

...

8. In the same thread [6], it was also suggested that Hana provides a way to write inline metafunctions, pretty much like MPL's lambda expressions. I think this is an interesting idea that could make simple type-level computations super easy to write and I will try to explore it in time for the formal review.

I'll be interested to see if/how you avoid Boost.MPL's lambda evaluation semantics quagmire. I find the business of tracking whether/where substitutions were done, conditionally probing for ::type, then conditionally selecting the substitution, to be pretty unsatisfactory. Too much magic, too difficult to grok, and could even cause errors by causing inadvertent instantiations of things not meant to be instantiated -- which means things need to be protect'ed, etc, etc. I would prefer a simpler, more predictable algorithm, even at the expense less pithy lambdas.

I too agree that MPL's lambda expressions are no fun, especially to implement. For Hana, I would aim for something much simpler because it would just be a way to quickly compose type-level computations in order to save a couple of lines. For more complex computations, my opinion is still that one should use plain functions. Regards, Louis

Steven Watanabe writes:

AMDG

On 03/17/2015 11:39 AM, Louis Dionne wrote:

...

<snip>

template auto foldr(Sequence xs, State s, F f) { if (is_empty(xs)) return s; else return f(head(xs), foldr(tail(xs), s, f)); }

<snip> since `f` never uses the value of its second argument, this argument is never evaluated. So the "else" branch inside the `foldr` becomes:

return f(thunk[head(xs)], thunk[foldr(tail(xs), s, f)]); --> return head(xs);

and the recursive call to `foldr` is never evaluated. This allows processing infinite lists lazily and writing short-circuiting algorithms such as

template bool any_of(Sequence xs, Predicate pred) { return foldr(xs, false, [](auto x, auto y) { return pred(x) || pred(y); }); }

I know this looks cool, but it's actually a perfect example of why foldr on an infinite sequence isn't a good idea. On an infinite sequence, this any_of will either return true or will go into infinite recursion. I can't see any practical use for such behavior. If I ever needed to use any_of on an infinite sequence, I doubt that having the false case fail would be acceptable. An any_of that actually handles the false case for infinite sequences can't be implemented generically. IMHO, foldr makes it much too easy to write algorithms like this that almost work.

Sorry for the late reply. Well, any_of might not have been the best example, but lazy right folds still make sense in a number of contexts. Being lazy when right-folding also allows interesting optimizations to take place (for example, see [1]), but that's a different story and we're far from there in Hana. On another note, I dismantled my germ of thought that lazy folding is just monadic folding with the Lazy monad; it's not that simple. I think achieving lazy right folds generically would require adding a generic expression evaluator that would be used everywhere to evaluate expressions, and then by overriding it one could pick between lazy and strict algorithms. I'm not sure though; I'm still trying to understand F-Algebras as presented by Bartosz in [2]. Anyway, so the conclusion is that lazy right folds won't be supported in Hana, at least not for a while. So this opens the door for renaming foldl/foldr to fold/reverse_fold. I'll probably start by adding aliases and then consider removing foldl/foldr, because renaming them all at once would require more work, especially with the new naming scheme with no-state overloads that was discussed in the poll at [3]. I hope this sounds reasonable. Regards, Louis [1]: http://goo.gl/hHzkuJ [2]: https://www.fpcomplete.com/user/bartosz/understanding-algebras [3]: https://github.com/ldionne/hana/issues/18

Edward Diener writes:

On 3/21/2015 10:20 AM, Louis Dionne wrote:

...

[...]

Anyway, so the conclusion is that lazy right folds won't be supported in Hana, at least not for a while. So this opens the door for renaming foldl/foldr to fold/reverse_fold. I'll probably start by adding aliases and then consider removing foldl/foldr, because renaming them all at once would require more work, especially with the new naming scheme with no-state overloads that was discussed in the poll at [3]. I hope this sounds reasonable.

I would like to urge you to use easily understandable names in your library rather than shortened and more cryptic names. Any extra typing a user of your library may have to do is easily offset by the fact that more easily understandable names make your library much more understandable to use.

Of course, my goal was never to use more cryptic names for the sole purpose of reducing the number of letters. When it makes sense to do so, I use the names that are used in C++. When there are good reasons not to, I use the names used everywhere else in functional programming. If you have specific examples of places where I use names that seem cryptic, please point them out. I will be happy to discuss the reasons behind those names and to change them if those reasons are deemed insufficient after consideration. Thank you, Louis Dionne

Edward Diener writes:

On 3/21/2015 12:11 PM, Louis Dionne wrote:

...

[...]  > If you have specific examples of places where I use names that seem cryptic, please point them out. I will be happy to discuss the reasons behind those names and to change them if those reasons are deemed insufficient after consideration.

A name like 'foldl' and 'foldr' is what I mean.

Quoting from my original reply to Steven: [...] So this opens the door for renaming foldl/foldr to fold/reverse_fold. I'll probably start by adding aliases and then consider removing foldl/foldr [...] It might not have been clear because I said "opens the door for [...]" and "probably start by [...]", but I actually meant that `fold` and `reverse_fold` __will__ be provided by Hana. The decision is already taken. I take it that the point of your intervention was to make sure this was the case. If you come across other functions that seem to be misnamed, please fill a GitHub issue so we can discuss the problem and resolve it. Regards, Louis

Edward Diener writes:

[...]

The point of my comment was to encourage not to you names like 'foldl/foldr' at all in your programming endeavors. Shorthand names rather than descriptive names always seems to me a bad way to program. No doubt I am sometimes guilty of it myself but the use of short but cryptic mnemonics always seems to me to be bad. Ages ago when memory was scarce and disk space was scarce the micro-computer world may have had a use for these short mnemonics, as in Unix/Linux etc., but nowadays I see no use for it. C++ very smartly has not pursued the cryptic mnemonics of C as a rule and I see little reason why good C++ programmers should ever follow the cryptic menemonics path anymore. It only makes functionality harder to understand and remember.

I understand your point, and I mostly agree with it. Even though I do not consider foldl/foldr to be cryptic, some other names following the same pattern give me nightmares (strto{k,d,f,l,ld,ll,ul,ull}, seriously?). So I think I understand how you can feel about fold{l,r}. However, for the case of `foldl` and `foldr` precisely, those functions are very well known in the functional programming community (see [1] for example). I think this constitutes a good motivation for using those names. This does not change the fact that fold/reverse_fold aliases will be provided for those that want it. I'll try to add them tomorrow. Regards, Louis [1]: http://goo.gl/ropQkM

Bjorn Reese writes:

On 03/22/2015 07:23 AM, Louis Dionne wrote:

...

I understand your point, and I mostly agree with it. Even though I do not consider foldl/foldr to be cryptic, some other names following the same

How about fold_outwards/fold_inwards (or fold/fold_inwards)

I don't understand which one should be which. I personally don't see how fold left is inwards (or outwards), and ditto for fold right. While aliases for people used to Fusion are provided, it is planned to have fold_right and fold_left, which everyone in the FP community can understand out of the box. See [1] for the resolution regarding foldl/foldr. Regards, Louis [1]: http://github.com/ldionne/hana/issues/18

Louis Dionne writes:

Dear Boost,

Here is a non-exhaustive list of some issues that were raised during the informal review of Hana last week, along with an explanation of what I did or am doing to resolve them.

[...]

4. It was suggested that `foldl` and `foldr` be renamed to something else. [...]

fold/reverse_fold aliases are now provided (see [1] for commit). Those aliases follow the behavior of Fusion/MPL closely, with the extension that it's possible to provide no initial state. Specifically, fold(sequence, state, f) == foldl(sequence, state, f) fold(sequence, f) == foldl1(sequence, f) reverse_fold(sequence, state, f) == foldr(sequence, state, flip(f)) reverse_fold(sequence, f) == foldr1(sequence, flip(f))

7. In a different thread [6], it was suggested that the Logical concept should interact well with Lazy computations. [...]

Arbitrary Lazy values and computations can now be used as branches to `eval_if` (see [2] for commit). More generally, anything that can be `eval`uated can be used as branches to `eval_if`, which means nullary lambdas: eval_if(condition, []{ return something; }, other_branch ) unary lambdas (useful for delaying instantiations, explained in the docs): eval_if(condition, [](auto delay) { return delay(f)(something); }, other_branch ) Lazy computations/values: eval_if(condition, lazy(f)(x, y, z), other_branch ) More syntactic sugar will probably be added so that `eval_if` looks prettier. Something along the lines of eval_if(condition)([]{ branch1 }).else_([]{ branch2 }) would be nice. I got this functionality (and more) locally, but I want to study all the possibilities before I check something in. Regards, Louis Dionne [1]: http://goo.gl/6hIWrA [2]: http://goo.gl/6yEhAz