ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
constexpr
boolean predicates as their implementation expects (What about a clite
branch?). Then I could continue haskellizing both TMP and C++ with Hana as the starting point.
curry
adaptor.
curry
adaptor to emulate automatic currying. This makes things like f <transform> x <ap> y <ap> z
equivalent to curry(f) <transform> x <ap> y <ap> z
, where <...>
is just infix application of …
.
f
a function inside an Applicative
and n
arguments inside the same Applicative
, I simply fmap curry f
, which gives me an Applicative
of curried functions.
lazy
adaptor would help.
lazy
adaptor, we can only get superficial laziness at one level.
lazy
except in some simple cases (e.g. for conditional statements), and this is also why the usual Haskell concepts are broken up into more parts (Iterable
, Foldable
and Searchable
instead of just Foldable
in Haskell).
Being frankly the only use case that comes to my mind for laziness (From the C++ point of view) are infinite ranges and related. In depth laziness and non-strict functions are cool, but their advantages may not worth the effort. Let's forget lazy for now (right fold included).
I'm gonna try to focus on translating the existing concepts to CL for now.
eval
. I’m not sure whether your eval
evaluates recursively, but it could be costly if it does. I don’t know for sure, but just be careful.
:point_up: May 3 2015 6:26 AM
eval
did full recursive evaluation at the beginning, but as Turbo evolved recursive evaluation has lost importance in favor of thinking of eval
as a way to evaluate all kind of expressions. Should I evaluate any template parameters prior to evaluate the template itself? I'm not that sure these days. Not for non-function templates. Also those should be evaluated lazily, not just evaluate the whole parameter list prior to function evaluation as I currently do. That's one of the reasons I'm focusing the effort on having comfortable curryable metafunctions.
::type
. This is what curry<…>::type
is; it just evaluates the curry<…>
value itself. It does not perform any kind of computation.
curry<1, f>
specialization that I evaluate the metafunction class with f::type::template apply<x>
. The f::type
part means: “unbox the metafunction f
”, and then call this with x
.
@ldionne got it thanks!
What I'm doing is to return a closure until the metafunctions accepts the arguments. That is, the metafunction is curryed until you enter all the arguments needed:
template<template<typename...> class Function>
struct curry
{
template<typename... Args>
struct apply
{
using f = just_t<Function, Args...>;
template<typename F, bool is_function = has_type<F>::value>
struct call
{
using type = typename F::type;
};
template<typename F>
struct call<F, false>
{
struct type
{
template<typename... Tail>
struct apply
{
using type = eval_mc<curry, Args..., Tail...>;
};
};
};
using type = typename call<f>::type;
};
};
just_t
tries to instance a template with the given arguments, else returns Nothing
. Of course Nothing
is not a metafunction nor has a ::type
member.
curry
utility handles variadic metafunctions?
template <typename ...T>
struct pack_size {
using type = std::integral_constant<std::size_t, sizeof...(T)>;
};