constexprboolean predicates as their implementation expects (What about a
clitebranch?). Then I could continue haskellizing both TMP and C++ with Hana as the starting point.
curryadaptor to emulate automatic currying. This makes things like
f <transform> x <ap> y <ap> zequivalent to
curry(f) <transform> x <ap> y <ap> z, where
<...>is just infix application of
fa function inside an
narguments inside the same
Applicative, I simply
fmap curry f, which gives me an
Applicativeof curried functions.
lazyadaptor would help.
lazyadaptor, we can only get superficial laziness at one level.
lazyexcept in some simple cases (e.g. for conditional statements), and this is also why the usual Haskell concepts are broken up into more parts (
Searchableinstead of just
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
evalevaluates 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<…>::typeis; it just evaluates the
curry<…>value itself. It does not perform any kind of computation.