Subject: Re: [boost] Template metaprogramming libraries
From: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-09-10 07:03:18
"Nested Lambda Expressions with Let Expressions in C++ Template
Metaprograms" explains metamonad's lambda expressions. The major
difference between that approach and MPL's lambda expressions is that
metamonad lambda expressions let the user specify the name of the
arguments instead of calling them _1, _2, etc. Using these lambda
expressions I could embed lambda expressions inside other lambda
expressions. The implementation of do-syntax relies on these lambda
expressions as well.
I'm not aware of techniques based on monads that help implementing
data-structues. They are good at abstracting behaviours (error handling,
non-determinism, etc.), they should help you with error propagation in
your algorithms (see compile-time exceptions in metamonad).
I've done a measurement: I've called "lazy_eval_if" / "eval_if + eager
condition evaluation" 1000 times (1.6GHz Atom processors, 1 GB memory,
Linux, GCC 4.5.2) and measured the compilation speed with "time". Here
are the results:
lazy_eval_if: 3.89 s
eval_if: 3.65 s
As you can see, there is some overhead (lazy_eval_if uses eval_if),
however it may be different with other compilers.
Am Freitag, den 09.09.2011, 20:05 -0400 schrieb Gordon Woodhull:
> On Sep 9, 2011, at 5:12 PM, Gordon Woodhull wrote:
> Okay I have read
> Functional Extensions to the Boost Metaprogram Library
> Now I get it, lazy extensions for MPL, and all the other goodies you would expect from a haskell-like functional programming library.
> And now monads too.
> Bravo! I hope you bring these libraries to Boost. I crave the simpler syntax and ability to create more complex of pure lazy evaluation.
> Have you measured compilation performance versus more-eager MPL implementations of the same algorithms, to see how bad the abstraction penalty is?
> I am looking at porting various Boost.Graph algorithms to my proposed MPL.Graph. Do I understand that monads will help me define metadata structures like heaps and forests that don't seem to "map" easily to functional programming?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk