Re: [proto] fold_tree and grammar using external_transforms and state
Le 27/07/2012 08:11, Eric Niebler a écrit : You mean, a proto callable that wraps fusion::transform? No, we don't have one yet. If you write one, I'll put it in proto. OK Naming is becoming an issue, though. We already have proto::transform. You'd be adding proto::functional::transform that would be totally unrelated. I think I screwed up with the namespaces. It should probably be proto::functional::fusion::transform. Urg. Well, I guess this is a breaking change :s What I need is maybe more generic as I need to apply an arbitrary function with arbitrary number of parmaeters, the first beign the flattened tree, the others begin whatever: transform( f, [a b c d], stuff, thingy ) => [f(a,stuff,thingy) f(b,stuff,thingy) f(c,stuff,thingy)] I'll try and ake it works out of the box first and see how it can be generalized. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] fold_tree and grammar using external_transforms and state
Yeah i figured the code was amiss. After corrections and using your tip, it works. The I discovered it was not what I wanted ;) What I actually need to do is that when I encounter a bunch of bitwise_and_ node, I need to flatten them then pass this flattened tree + the initial tuple to the equivalent of fusion transform that will do: skeleton_grammar(current, current value from state, current external_transforms) I guess proto::functional::transform is not there and need to be done by hand ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] fold_tree and grammar using external_transforms and state
Here is the deal: https://gist.github.com/3182676 THis code defines a DSL that allwo creating combo of functions using the following semantic: (task(f) | task(g))(x) computes g(f(x)) (task(f) & task(g))(x) computes make_tuple(x)),g(at<1>(x))> We use external_trasnforms here because we will have other evaluation strategy depending on the platform. We pass the initial value to compute as a state to the grammar and the data is the xternal transform. The problem is that I can't get the fold_tree to work in this setup as I guess the fold _state conflict with my own grammar _state. Am I being dense or is it a limitation ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Precomputing common matrix products in an expression
Le 13/07/2012 23:55, Eric Niebler a écrit : This is an instance of the larger "common subexpression elimination" problem. The problem is complicated by the fact that it can't be solved with type information alone. u_adv*nable(u) might have the same type as u_adv*nable(v) but different values. A hybrid solution is needed where you cache a set of results indexed both by type information and the identities (addresses) of the constituents of the subexpressions. This is hard, and nobody has attempted it yet. I can give you encouragement, but not guidance. If you find a general and elegant solution, it would certainly be worth putting in Proto, since lots of folks would benefit. In NT2, we use a schedule transform that iterate the expression tree and evaluate expression tagged as being needed to be evaluated once and store them in some shared_ptr like terminal. This allow us to "schedule" our loop nests in the proper order. This "scheduling" is what requried us to store everything proto by value inside expression. Mathias correct me if I diverge. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto-11 progress report
On 06/24/2012 01:10 AM, Eric Niebler wrote:
I've made some good progress on the C++11 proto rewrite that I'd like to
share. So far, it's been a less radical shift than I expected.
You didn't try hard enough ;)
Expressions vs. Grammars
Many new users are confused by the difference between terminal and
terminal::type. In proto.next, there is no difference. Forget the
::type. Things just work.
Neat
Custom transforms are simpler
=
Currently, defining a custom transform means defining a struct with a
nested impl class template of 3 parameters, correctly inheriting and
following a protocol. In the rewrite, I wanted to simplify things. Here
for instance, is how the _expr transform is defined:
struct _expr
: transform<_expr>
{
template
auto operator()(E && e, Rest &&...) const
BOOST_PROTO_AUTO_RETURN(
static_cast(e)
)
};
A custom transform is simply a struct that inherits from
proto::transform and that has an operator() that accepts an arbitrary
number of parameters. (The use of BOOST_PROTO_AUTO_RETURN is not
necessary. It simply handles the return statement, the return type, and
the noexcept clause.)
Good
Data parameter uses a slot mechanism
In proto today, transforms take 3 parameters: expression, state and
data. As you can see from above, transforms in proto-11 take an
arbitrary number of parameters. However, that can make it hard to find
the piece of data you're looking for. Which position will it be in?
Instead, by convention most transforms will still only deal with the
usual 3 parameters. However, the data parameter is like a fusion::map:
it will have slots that you can access in O(1) by tag.
Here is how a proto algorithm will be invoked:
int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);
The 3rd parameter associates the value 8 with the data tag. The _data
transform returns the data associated with that tag. Additionally, you
can define you own tags and pass along another blob of data, as follows:
int i = LambdaEval()(_1 + 42, 0, (proto::tag::data = 8, mytag = 42));
The _data transform will still just return 8, but you can use
_env to fetch the 42. The third parameter has been
generalized from an unstructured blob of data to a structured collection
of environment variables. Slots can even be reused, in which case they
behave like FILO queues (stacks).
How do you set up new tag ? Is just mytag some
mytag_type mytag = {};
?
or should mytag_type inherit/be wrapped from some special stuff
As for what is not changing:
Grammars, Transforms and Algorithms
===
It would be wonderful if there were a more natural syntax for describing
proto algorithms rather than with structs, function objects, proto::or_,
proto::when, and friends. If there is one, I haven't found it yet. On
the up side, it means that many current proto-based libraries can be
upgraded with little effort. On the down side, the learning curve will
still be pretty steep. If anybody has ideas for how to use C++11 to
simplify pattern matching and the definition of recursive tree
transformation algorithms, I'm all ears.
There is not so much way to describe something that looks like
a grammar definition anyway. BNF/EBNF is probably the simplest
way to do it.
Now on the syntactic clutter front, except wrapping everything in round
lambda
or use object/function call in a hidden decltype call, I don't see what we
can do better :s
Glad it is picking up steam :D
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] [proto-11] expression extension
Just a question that just struck me. Will this rewrite be backward compatible with C++03 for the features that make sense ? I think the C++03 version may benefit from the new expression extension mechanism etc. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Who's using proto ?
Hi, i'm in the process of writing a journal paper about proto and I wanted to give a realistic snapshot of who is using proto and for what. I know some already (the whole MSM & Spirit team etc ) but i am sure there is other people lurking around here. So, if you want to contribute, I wish any of you, proto user, to tell me who you are, what you're using proto for and if you have a reference (for academic) or a website (for other). It's a win-win as you may get exposure and you help us make this paper a nice PR for proto. Of course, you can do this on the list or in private if you prefer. Thanks in advance. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] [proto-11] expression extension
Le 04/06/2012 21:18, Eric Niebler a écrit : The make_expr function object takes as arguments the tag and the children. You can do whatever you want. If open extensibility matters, you can dispatch to a function found by ADL or to a template specialized on the tag like proto::switch_. It's up to you. Ok perfect Not sure what you mean. Are you referring to the current discussion about having to use shared_ptr to store something? That seems unrelated to me. Assuming your types are efficiently movable, the default should just do the right thing, and your expression trees can be safely stored in local auto variables without dangling references. Does that help? I was thinking of the case where we constructed a foo expression by calling expression constructor one into the other. I guess it fixes that. Proto-11 will probably take many months. I'm taking my time and rethinking everything. Don't hold your work up waiting for it. No problem, just that if you need some reality check at some point we may provide a non trivial test case. We're doing it anyway ;) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] restructuring expression
On 01/06/2012 07:55, Eric Niebler wrote: However, it means that you will no longer be able to use a proto grammar as a generator. That was cute functionality, but I don't think it was terribly useful in practice. How do folks feel about the loss of that functionality? I personnally never used it. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] [proto-11] expression extension
On 03/06/2012 09:41, Eric Niebler wrote: Hey all, this is just an FYI. I've been hard at work at a ground-up redesign of proto for C++11. Great news ! 1) Rather than writing expression wrappers, you'll be writing actual expression types. Proto provides helpers that make this easy. To get the basics, inherit from basic_expr. To get tree-building assign, subscript, and function call operators, inherit from expr_assign, expr_subscript and expr_function respectively. I make a lot of sense actually. 2) Rather than writing generators, you'll be defining per-domain make_expr function objects that accept a tag and a number of children. How you decide to assemble these into an expression is up to you, but you can use a helper like make_custom_expr above to simplify things. It's very important those make_expr functino object could be extended externally of any structure. By the look of it, it looks like it'll behave similary to the switch_ construct, aka a template functor inside a struct to be extended outside. 3) There are other per-domain customization points: (a) store_value, which specifies the capture policy for non-proto objects in expressions, and (b) store_child, which specifies how children are stored. For both (a) and (b), the default is: lvalues are stored by reference and rvalues are stored by (moved from) value. Expressions can safely be stored in auto variables by default. So I guess it also fix the problem we faced with Mathias on having to store everythign by value to have proper chains of expression building function works properly ? Thanks all for now. Feedback welcome. If you have wishlist features for proto-11, speak now. On eo fmy PHD student will start converting Quaff to C++11 this july, so depending on your advancement on Proot-11, we may give it a shot an dreport any missing features. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] restructuring expression
On 05/29/2012 08:21 PM, Eric Niebler wrote: On 5/29/2012 1:44 AM, Karsten Ahnert wrote: I have an arithmetic expression template where multiplication is commutative. Is there an easy way to order a chain of multiplications such that terminals with values (like proto::terminal< double>) appear at the beginning? For example that arg1 * arg1 * 1.5 * arg1 will be transformed to 1.5 * arg1 * arg1 * arg1 ? I can imagine some complicated algorithms swapping expressions and child expressions but I wonder if there is a simpler way. There is no clever built-in Proto algorithm for commutative transformations like this, I'm afraid. I was going to suggest flattening to a fusion vector and using fusion sort, but I see there is no fusion sort! :-( Nevertheless, that seems like a promising direction to me. Once you have the sorted vector, you should(?) be able to use fusion::fold to build the correct proto tree from it. Won't having a way to build it properly from the get go be a better solution ? This basically require the feature we spoke about earlier so that building a X * Y node check which from X or Y is a double and put it in the proper place ? Then when doing X * Expr, check if there is a double at child<0> of expr and restructure the whole tree at generation time ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Restructuring noses in generator
On 04/29/2012 02:41 AM, Eric Niebler wrote: And some_terminal is not in your domain? How does your generator get invoked? I guess I'm confused. Can you send a small repro? everything is in my domain, no problem ont his side, I'll try Mathias idea and report if anything breaks. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Restructuring noses in generator
How can I use a custom generator to turn a specific node expression into a different version of itself without triggering endless recursive call ? My use cas is the following, i want to catch all function node looking like tag::function( some_terminal, grammar, ..., grammar ) with any nbr of grammar instances into tag::function( some_terminal, my_tuple_terminal, some_other_info ) basically makign n-ary function node into ternayr node with a specific structures. Of course this new node should live in whatever domain some_terminal is coming from. My first attempt was using make_expr in my generator but it endlessly looped at compile time. Is there somethign I am missing ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] The proper way to compose function returning expressions
On 04/24/2012 12:15 AM, Eric Niebler wrote: implicit_expr() returns an object that holds its argument and is convertible to any expression type. The conversion is implemented by trying to implicitly convert all the child expressions, recursively. It sort of worked, but I never worked out all the corner cases, and documenting it would have been a bitch. Perhaps I should take another look. Patches welcome. :-) I think this is an important issues to solve as far as Proto grokability does. One of my coworker on NT2 tried to do just this (the norm2 thingy) and he get puzzled by the random crash. I think we should at least document the issues (I can write that and submit a patch for the doc) and maybe resurrect this implicit_expr. Do you have any remnant of code lying around so I don't start from scratch ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] The proper way to compose function returning expressions
Let's say we have a bunch of functions like sum and sqr defined on a proto domain to return expression of tag sum_ and sqr_ in this domain. One day we want to make a norm2(x) function which is basically sum(sqr(x)). My feeling is that I should be able to write it using sqr and sum expressions. Alas it seems this results in dandling reference, crash and some sad pandas. Then I remember about proto::deep_copy but I have a worries. x is usually a terminal holding a huge matrix like value and I just don't want this huge matrix to be copied. What's the correct way to handle such a problem ? How can I build new function returning expressions built from expression composition without incurring a huge amount of copy ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Held nodes by value for Fundamental types
On 10/04/2012 00:00, Eric Niebler wrote: Thanks. I thought long about whether to handle the fundamental types differently than user-defined types and decided against it. The capture-everything-by-reference-by-default model is easy to explain and reason about. Special cases can be handled on a per-domain basis as needed. By-value capture of fundamental type is the classical way people do it in hand-made ET code. The ad-hoc support in proto is IMHO better as you may really want to capture reference and by the status of Proto of a EDSL toolkit, flexibility is really wanted :). ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Grouping expressions
On 30/12/2011 17:34, Bart Janssens wrote: On Fri, Dec 30, 2011 at 7:01 AM, Eric Niebler wrote: Are you certain your problem is caused by using operator() for grouping? I think this is just a very big expression template, and any syntax you choose for grouping will result in long compile times and heavy memory usage. Yes, that's what I mean, the way grouping works now always creates a huge expression. You cant really do anything else. ET captures the whole AST and this AST has to be stored somehow. Can I ask, what version of Boost are you using? I see you #define BOOST_PROTO_MAX_ARITY to 10 at the top. In recent versions of Proto, 10 is the default. And newer Proto versions already make use of variadic templates for operator() if available. I'm using 1.46.1 for now. Good to hear variadic templates are already available for this, do I need to do anything explicit to enable them, such as add a compile option? Compiles in C++11 mode : --std=c++0x Other things to think about: does this really need to be all one big expression, or can parts of it be broken up and type-erased, as with spirit::qi::rule? Not sure how this type-erased method works, but all of the expressions are ran in a tight loop, so I'd like to avoid the overhead of having to go through a virtual call. Also, I use some introspection across the whole expression to determine which variables exist. type erasure allow your template class to inherit from a single, non-template base class that forward its evaluation to its actual derived class via a single virtual member function entry-point. At some point, you need to do this or your CT just explode. And for your performance matter, I think it need to be benched, type erased calls usually are no more than some cycles slower to call. On the front of introspection, we found out in NT2 that performing some introspecting tasks in the expression generator (when it made sense) helped keep the CT madness low as the resulting AST can be trimmed as soon as it is built. Not sure if it applies here. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Extendin proto::switch_
Le 29/08/2011 17:33, Eric Niebler a écrit : Good. Obviously, this needs to be called switch_ instead of select_. Sure I was testing the water inside nt2 first There needs to be an appropriate default for the Transform parameter, something like tag_of<_>(). There should also be a specialization of switch_ when the transform is tag_of<_>() to make it as efficient as the current switch_ (but it should be backward-compatible without the specialization -- test this!). And of course docs and tests. Yup. No need to replace the internal use of when, but you can access when's nested impl template directly instead of using result_of's needlessly complicated machinery. See the implementation of if_. OK great then :) I have to come back from a conference and I'll start pushing this to trunk as soon as it looks pretty. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Extendin proto::switch_
Le 06/08/2011 08:10, Eric Niebler a écrit : On 8/5/2011 10:55 PM, Joel falcou wrote: On 06/08/11 07:30, Eric Niebler wrote: That wouldn't be enough because proto::matches "knows" about proto::switch_. It would be easy enough to extend proto::switch_ to take an optional mpl metafunction that accepts and expression and returns a type to dispatch on. It would default to proto::tag_of. Or for the sake of consistency with the rest of proto, it should probably be a transform, in which case it would default to proto::tag_of(). OK Could you open a feature request? Well, we wanted to know the correct road, i have someone to do it, so let's say we'll provide you with a patch request instead ;) Even better. :-) Here is a first try: https://github.com/MetaScale/nt2/blob/30251fccec639a3823179fc04100fb3fba0688b2/modules/sdk/include/nt2/sdk/dsl/select.hpp Not sure it is perfect but it works eemingly :) My main cocnern is can i get to remove this internediate when + result_of ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
Le 26/08/2011 17:56, Eric Niebler a écrit :
On 8/26/2011 11:44 AM, Eric Niebler wrote:
Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector domain.
In short, there is no requirement that a domain's generator must produce
expressions in that domain. Just hack matrix_domain's generator.
Expanding on this a bit ... there doesn't seem to a sub-/super-domain
relationship between matrix and vector. Why not make them both (together
with covector) sub-domains of some abstract nt2_domain, which has all
the logic for deciding which sub-domain a particular expression should
be in based on its structure? Its generator could actually be a Proto
algorithm, like:
nt2_generator
: proto::or_<
proto::when<
vector_grammar
, proto::generator(_)>
proto::when<
covector_grammar
, proto::generator(_)>
proto::otherwise<
proto::generator(_)>
>
{};
struct nt2_domain
: proto::domain
{};
Etc...
I think you hit it right on the spot. I'll see how to make this
consistent with table and other stuff.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
Le 26/08/2011 17:44, Eric Niebler a écrit :
On 8/26/2011 11:23 AM, Joel Falcou wrote:
On 26/08/2011 17:18, Eric Niebler wrote:
Why can't you use a grammar to recognize patterns like these and
take appropriate action?
we do. Another point is that container based operation in our system
need to know the number of dimension of the container. Domains carry
this dimensions informations as we dont want to mix different sized
container in a same expression. The containers we have are :
table which can have 1 to MAX_DIM dimesnions matrix which behave as
table<2> when mixed with table covector and vector that act as a
matrix when mixed with matrix adn table<2> with table.
The domain are then flagged with this dimension informations.
OK, then I'll just assume you guys know what you're doing ('cause you
clearly do).
Except ... read after that
The answer is no, but you don't need that, I don't think. Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector domain.
In short, there is no requirement that a domain's generator must produce
expressions in that domain. Just hack matrix_domain's generator.
OK, if we can do that, in fact, we can remove the meta_informations from
the domain all together and just have table_domain and
matrix/vector/covector_domain then use a hacked geenrator to do all the
checking/recreation we need. I guess we can handle the checking on size,
gemm/gemv proper sytsem in the generator and allow m * v in matrix
grammar etc ... And this hacked generator can static_assert proper
message when uncomaptible stuff get mixed.
Again seems proto lack of some obscure feature I thought necessary makes
my problem clearer. Put this on hold then, I'll try to come up with a
better implementation of my domain handling.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 17:27, Brandon Kohn wrote: I solved this kind of problem by tagging the various types in traits structs and then embedding these traits in the transforms for the various operations. Here are examples of my expression, grammar, and binary function definitions: https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/expression.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/grammar.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/binary_functions.hpp I'm not sure if this is the best way to do these, but it does work. These coudl be grammar. Anytime you want to have somethign selecting somethign based on expression structure, it is a grammar. Such metafonction systems ar eusualyl brittle or not extensible enough. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 17:18, Eric Niebler wrote: Why can't you use a grammar to recognize patterns like these and take appropriate action? we do. Another point is that container based operation in our system need to know the number of dimension of the container. Domains carry this dimensions informations as we dont want to mix different sized container in a same expression. The containers we have are : table which can have 1 to MAX_DIM dimesnions matrix which behave as table<2> when mixed with table covector and vector that act as a matrix when mixed with matrix adn table<2> with table. The domain are then flagged with this dimension informations. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 16:45, Eric Niebler wrote: Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. We have a system of specialisation where being able to make this distinction allowed us to replace sub proto tree by a pregenerated call to some BLAS functions or to apply some other Linear Algebra math based simplification. We also have a covector domain which allow us to know that : covector * vector is a dot product while vector * covector generate a matrix. In the same way, covector * matrix and matrix * vector can be recognized and handled in a proper way. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Extendin proto::switch_
On 06/08/11 21:01, Eric Niebler wrote: Besides, enable_if is yuk. Care to elaborate (not like we use it like over 9000 times in our code base) / ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Extendin proto::switch_
On 06/08/11 07:30, Eric Niebler wrote: That wouldn't be enough because proto::matches "knows" about proto::switch_. It would be easy enough to extend proto::switch_ to take an optional mpl metafunction that accepts and expression and returns a type to dispatch on. It would default to proto::tag_of. Or for the sake of consistency with the rest of proto, it should probably be a transform, in which case it would default to proto::tag_of(). OK Could you open a feature request? Well, we wanted to know the correct road, i have someone to do it, so let's say we'll provide you with a patch request instead ;) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Extendin proto::switch_
There is few use case where I wish i can have a proto::switch_ like transform being extendable externally but based on something else than the expression tag like the result of an arbitrary meta-function. Is cloning proto::swicth_ and changing the way it dispatch over its internal cases_ enough ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Expression as *other* fusion sequence
On 17/06/11 01:25, Eric Niebler wrote: Doable, but not easy. The problem you'll have is that all Proto expression types have a nested fusion_tag that is a typedef for proto::tag::proto_expr. That is how Fusion figures out how to iterate over Proto expressions. You'll need to define your own tag, use proto::extends (not BOOST_PROTO_EXTENDS) to define an expression extension, and hide the fusion_tag typedef in the base with your own. Then you'll need to implement the necessary Fusion hooks for your custom Fusion tag type. OK, but is there any internal proto part relying on the proper fusion behavior that may get hampered by this ? I'll give it a try :) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Expression as *other* fusion sequence
proto expression are fusion sequence that iterates over the node children. All fine and dandy. Now here is my use case. I have expression whose terminal are fusion sequence that access tot he terminal values (think terminal holding a std:;array for example) and I wished to have expression of the terminal be fusion sequence themselves so i can do stuff like : at_c<0>( x + y * 3 ) where x and y are such terminals, this statement returning me the equivalent of : at_c<0>( x ) + at_c<0>( y ) * 3 Obviously, no candy as both fusion registration conflicts with each others. My Fusion-fu beign quite weak, is there a way to have this AND still have proto expressions behave as they should in other context ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] [Proto] Expression as fusion/MPL sequence
Seems somethign crooky on this front. Calling fusion::at_c on expression ends up in error even after including boost/proto/fusion.hpp. Same way, flatten used as a transform seems to not give me a type that can be passed to any fusion or mpl function. Looking at proto/fusion.hpp I noticed that the iterator is indeed random_access but not the view itself which as a forward_traversal tag. Even after fixing this, no dice, at_c(some_proto_expr) still fails to compile. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Latest proto commit on trunk.
On 09/05/11 20:36, Eric Niebler wrote: Right, that's not going to work. I'm surprised it ever did. it was long shot by us I confess. I'll repent I promise Can you you boost/typeof.hpp For w/e reason it fails horribly in flames and brimstone under MSVC2010 in our test cases. PROTO_DECLTYPE dont ... ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Latest proto commit on trunk.
On 09/05/11 21:12, Eric Niebler wrote: FWIW, this was due to a missing #include, which I've since fixed. This *should* work again, but it's not part of Proto's public documented interface. I reserve the right to break your code. ;-) No problem. This is anyway some ugly fix. We have to slaps MSVC in the face harder. Thanks for the timely commit, I'll report nt2 compile time improvement as soon as my box is not sluggish anymore ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Latest proto commit on trunk.
I got these error compiling NT2 with proto trunk /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:56: error: 'M0' has not been declared /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected identifier before '~' token /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected ')' before '~' token /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: ISO C++ forbids declaration of 'BOOST_PP_REPEAT_1_BOOST_PROTO_MAX_ARITY' with no type /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected ';' before '~' token Our code is : #include #include #if BOOST_WORKAROUND(BOOST_MSVC, >= 1600) && defined BOOST_NO_DECLTYPE #undef BOOST_NO_DECLTYPE #endif #include #define NT2_DECLTYPE(EXPR, TYPE) BOOST_PROTO_DECLTYPE_(EXPR, TYPE) Is detail/decltype.hpp a no-go to reuse this way ? As for why we do this, we have to fight against some MSVC bug w/r to decltype that PROTO_DECLTYPE seemed to fix. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Using make_expr with as_child or as_expr
On 01/05/11 04:41, Eric Niebler wrote: In some cases, I really want to write something like proto::make_expr( proto::as_child(a0), proto::as_child(a1) ) but that kind of thing doesn't work, due to the funny way make_expr works. It doesn't work? I *think* that would have the effect of building a new node that would store children by value, making a0 and a1 expressions (if they weren't already) by storing the terminal by reference. Is that not what you were expecting? What are you trying to do? We were expecting exactly that. It turned up something is still kept by reference and cause the code to crash due to dandling references. If you say it should work, we may have fumbled elsewhere. We'll try to get a repro out of nt2. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Flags expression as being "top level"
Hello, we need a way to know if a given expression is the "top level" one. The use case is to detect the last = in expression like: a = b = c = x * y; A working but runtime version is given as : http://codepad.org/MO2NUgI2 Havign this feature at compiel time sounds a lot better. I think it requires to have a expression type carrying a bool_ in its type. Thus in the generator, we set this bool_ to false_ in incoming expression and put it back into the newly generated expression. Is this a correct way of doing this or is there somethign already in proto we missed ? Regards ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] My own lambda for MSM / wish list
On 14/03/11 22:28, Christophe Henry wrote: .. the talk from Matt Calabrese last year at boostcon with the MPL/Fusion hybrid using decltype and auto. I think this is an interesting venture all in all and should be extended. Yes, I have this in mind too. I think it is worthy of *at least* consideration. MAtt said some stuff was still edgy but the core is probably here. Sure! Count me in! And add Gordon to the pool. As for who working when and how long, take into consideration i have some part of my own research programm trying to get started on that, so I can dedicate more than just my free time to this. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] My own lambda for MSM / wish list
On 14/03/11 04:49, Eric Niebler wrote: Exciting stuff! Truly Christophe, your ideas re decltype and EDSLs in C++ are revolutionary. But unfortunately, I fear it will require a revolution. This is all do-able, but the changes to MPL, Proto and even to Phoenix in the case of the lambda capture stuff would require breaking API changes. The main problem is that we still segregate type operations from their runtime counterpart, this leads me to ... As for MPL and Proto, someone needs to sit down and do some hard thinking about what meta-programming will look like in C++0x. I suspect it'll look less like today's MPL and Proto, and much more like what you envision. It's a huge opportunity for someone to do some really ground-breaking work. .. the talk from Matt Calabrese last year at boostcon with the MPL/Fusion hybrid using decltype and auto. I think this is an interesting venture all in all and should be extended. I have the same kind of ideas Christophe plus a few other (including a real meta-DAG structure). Maybe we should get Matt in our boat and try hammering stuff ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Nested Transforms
On 26/02/11 12:55, Eric Niebler wrote: But maybe it wouldn't hurt. Maybe RVO kicks in. It's worth testing. Joel F., are you listening? Yours is probably the most performance sensitive application of Proto. Can you try compiling with BOOST_PROTO_STRICT_RESULT_OF and let us know if there's a perf hit? Will do asap and report ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Inter-domain interaction - Question and bug ?
On 26/02/11 10:50, Eric Niebler wrote: Sure. This is pretty easy. I suggest you introduce an additional unary node with a special tag that is recognized by your grammar. For instance, exponentbits currently returns: unary_expr< exponentbits, arg> Instead, make it return: unary_expr< exponentbits, unary_expr< hidedomain, arg> > Now, add the following alternate to your grammar: unary_expr< hidedomain, _> Make sense? Eric, once again, your brain > my brain. I'll test this asap. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Nested Transforms
On 26/02/11 02:18, Nate Knight wrote: I'm trying to understand why the two commented out lines fail to compile. It seems to me that ideally they would compile, but I may be missing some constraint that makes these lines incorrect. In the first case, it seems like the return type of the default subscript evaluator is being computed incorrectly. The second one is not as interesting, but I curious why it doesn't compile. I'm compiling against 1.45 with gcc 4.5. Thanks for any help. Do you have the compilation output for each failure separately. I dont have a compiler handy atm. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Inter-domain interaction - Question and bug ?
Hi,
while adding function to my SIMD library built on proto. I stumbled into
this problem:
http://codepad.org/dd5WB8Xu
I have a template grammar/generator/domain that helps me not mixing
vector of different type/cardinal.
However some functions are designed to take vector of float and turn
them into vector of int.
I wrote one there (exponenbits) by just forcing the domain to be the one
from int. When I call it alone, it works.
But if I do exponentbits( some_float ) + some_int doesnt work.
The error is just :
/Users/joelfalcou/nt2/sandbox/proto.cpp:161:46: error: no match for
'operator+' in 'nt2::simd::exponentbits(((const nt2::simd::pack4ul>&)((const nt2::simd::pack*)(& x + y'
With none of the usual 'no proto_grammar in not_a_domain' error I got
when I mix element of different grammar with each other.
Now, if i turn the grammar into:
// the template grammar
template
struct grammar
: boost::proto
::or_ < boost::proto::terminal< data >
, boost::proto::unary_exprgrammar >
, boost::proto::
and_< boost::proto::
nary_expr < boost::proto::_
, boost::proto::vararg< grammar >
>
, boost::proto::
not_< boost::proto::or_ < boost::proto::
address_of< grammar >
, boost::proto::
dereference< grammar >
, boost::proto::
comma < grammar
, grammar
>
>
>
>
>
{};
It works. Alas, I have a potentially high and extensible set of such
function (some being binary or ternary or w/e) and so I want
some way to accept such constructs without an explicit list of supported
function. nt2 currently has something like 17 such cross domain function.
My question is why building such an expression:
- make an error. Once I wrapped a terminal of domain Foo in domain
Bar, it should be composable with other element of Bar domain
- if this is an error, why dont I get the usual error of mixing wrong
element with each other ?
Mixing element from unrelated domain through such domain wrapping is a
very valauble techniaues in EDSL in my opinion as it allows efficient
operations to be done.
nt2 has a vector and covector class in different domain and transposing
a vector yields a covector, and vice versa. Being able to just have
somehting that wraps the vector terminal and change its semantic this
way is very valuable.
Thansk for any pointers or discussion on this.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 12:41, Eric Niebler wrote: On 2/20/2011 6:40 PM, Joel Falcou wrote: On 20/02/11 12:31, Karsten Ahnert wrote: It is amazing that the proto expression is faster then the naive one. The compiler must really love the way proto evaluates an expression. I still dont really know why. Usual speed-up in our use cases here is like ranging from 10 to 50%. That's weird. Well, for me it's weird in the good way so I dont complain. Old version of nt2 had cases where we were thrice as fast as same vector+iterator based code ... ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 12:31, Karsten Ahnert wrote: It is amazing that the proto expression is faster then the naive one. The compiler must really love the way proto evaluates an expression. I still dont really know why. Usual speed-up in our use cases here is like ranging from 10 to 50%. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 12:03, Karsten Ahnert wrote: On 02/20/2011 12:02 PM, Joel Falcou wrote: On 20/02/11 11:55, Karsten Ahnert wrote: On 02/20/2011 11:57 AM, Eric Niebler wrote: It gcc 4.4 on a 64bit machine. Of course, I compile with -O3. Ding! welcome to gcc-4.4 64bits compiler hellfest. Try 4.5, 4.4 64bits can't inlien for w/e reason. Great, I tried with gcc 4.5 and the proto part is now around 5-10 percents faster. Thank you. We banged our heads for weeks on this issue earlier until we found some dubious bug report in gcc bugzilla flagged as nofix :/ Seems the 4.5 branch solved it somehow. You cna also try compiling with 4.4 using -m32 ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 11:55, Karsten Ahnert wrote: On 02/20/2011 11:57 AM, Eric Niebler wrote: It gcc 4.4 on a 64bit machine. Of course, I compile with -O3. Ding! welcome to gcc-4.4 64bits compiler hellfest. Try 4.5, 4.4 64bits can't inlien for w/e reason. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 11:57, Eric Niebler wrote: On 2/20/2011 5:52 PM, Joel Falcou wrote: 1/ how do you measure performances ? Anything which is not the median of 1-5K runs is meaningless. You can see how he measures it in the code he posted. I clicked send too fast :p 2/ Don't use context, transform are usually better optimized by compilers That really shouldn't matter. Well, in our test it does. At least back in gcc 4.4 3/ are you using gcc on a 64 bits system ? On this configuration a gcc bug prevent proto to be inlined. Naive question: are you actually compiling with optimizations on? -O3 -DNDEBUG? And are you sure the compiler isn't lifting the whole thing out of the loop, since the computation is the same with each iteration? Oh yeah I forgot these. On my machine (mac osx dual core intel with g++4-5) i have a 25% speed up by proto ... ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
1/ how do you measure performances ? Anything which is not the median of 1-5K runs is meaningless. 2/ Don't use context, transform are usually better optimized by compilers 3/ are you using gcc on a 64 bits system ? On this configuration a gcc bug prevent proto to be inlined. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Active operator/function generation checking
On 31/01/11 04:38, Eric Niebler wrote: This is a judgment call that only you, as library author, can make. If doing the checking early imposes too high a compile-time requirement, then it may make sense to delay it until it's less expensive to do, and accept worse error messages. *nods* But at least, I am not doing something completely stupid at this level. You might also consider a "debugging mode" controlled with a compiler switch, where things are checked up-front. Just a suggestion. I was thinking of this too, and add some NT2_COMPILE_TIME_DEBUG mode. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Active operator/function generation checking
I'm trying to polish the last layer of compile time error handling in nt2. my concern at the moment is that, if have a function foo(a,b) that works on any real a and any char b, i dont want my foo function working on nt2 container to work with nothing but matrix of real and matrix of char. nt2 has a is_callable_with metafunction that basically check for this on the scalar level. Considering the huge amount of functions nt2 has to support and their complex type requirement, grammar are a bit unusable here. Is it OK to have a custom nt2 generator that basically static_assert over is_callable_with to prevent wrong container expression to be built and hence ends up in error waay far in the expression evaluation code ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Error found.
The problem was in the and_impl transform. It uses comma operator to
chain calls to each and_ alternatives.
However, when this is used in a grammar used as a Generator, it enters a
subtle infinite loop as each comma
want to build an expression with the newly generated expression.
I locally modified proto this way in boost/proto/matches.hpp :
templateState, typename Data>
struct _and_impl, Expr, State, Data>
: proto::transform_impl
{
#define M0(Z, N,
DATA)\
typedef
\
typename proto::whenN)>\
::template implData>\
BOOST_PP_CAT(Gimpl,
N); \
/**/
BOOST_PP_REPEAT(N, M0, ~)
typedef typename BOOST_PP_CAT(Gimpl, BOOST_PP_DEC(N))::result_type
result_type;
result_type operator()(
typename _and_impl::expr_param e
, typename _and_impl::state_param s
, typename _and_impl::data_param d
) const
{
// Fix: jfalcou - 12/29/2010
// This allow and_ to be used in grammar used as generator
// by not using comma which caused an infinite loop
#define M1(Z,N,DATA) \
BOOST_PP_CAT(Gimpl,N)()(e,s,d);\
/**/
// expands to G0()(e,s,d); G1()(e,s,d); ... G{N-1}()(e,s,d);
BOOST_PP_REPEAT(BOOST_PP_DEC(N),M1,~)
return BOOST_PP_CAT(Gimpl,BOOST_PP_DEC(N))()(e,s,d);
}
#undef M1
#undef M0
};
instead of using comma, I just generate N-1 application of GimplN and
return the last Gimpl call.
Is this fix acceptable or am I doing something wrong all together ?
If yes, Eric, any objections that I merge this into trunk ?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
OK, small road bump.
I tried a simple "grammar as geenrator" thingy but using the idea that i
didnt wanted to replicate all possible generator out there.
So i made a template grammar taking a Generator and doing thing around:
struct print_tag : proto::callable
{
typedef void result_type;
template void operator()(X const&) const
{
std::cout << typeid(typename proto::tag_of::type).name() << "\n";
}
};
template
struct debug_generator
: proto::when < proto::_
, proto::and_ < print_tag(proto::_)
, Generator(proto::_)
>
> {};
I then took the Calc2 example and changed the calculator_domain to be :
struct calculator_domain
:
proto::domain > >
{};
Boost version is 1.45
The full modified code is : http://codepad.org/41nnNNwf
Alas, I got a lump of errors as specified here : http://codepad.org/4hnylfvQ
Am I missing something or is the and_ not working like I thougt it was
as a transform.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Disregard last question. a generator is just a callable, so i can use a grammar as a generator I guess hence using the grammar to dispacth the proper actions on my ast construction. Am I right ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Last question. The geenrator awaits a Expr as parameters, what can be the way to specialize this operator() dependign on the tag passed to the generator ? Extract tag_of out of Expr and then dispacth internally ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
On 28/12/10 23:13, Eric Niebler wrote: On 12/28/2010 5:05 PM, Joel Falcou wrote: Here i smy use case. I guess Eric answer will be "do this at evaluation time" Do this at evaluation time. Just kidding. See :p I was *sure* you will say that :p You missed the "Generator" parameter to proto::domain. It's a unary function object that accepts all new proto expressions and does something to it. That something can include asserting if matrix/vector sizes don't match. Oh snap ! Of course. I just have to make my generator do the same stuff than normal proto generator except asserting before. I also see that i can make this Generator subject to some of our policy to enable?disable this at compile-time. OK Sold :D ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Adding stuff in proto operator
Here i smy use case. I guess Eric answer will be "do this at evaluation time" but let's I have some array/matrix DSEL going on. I want to test if two expression containing said matrix has compatible size before creating a proto ast node. e.g if a,b are matrices, a + b should assert if size(a) != size(b) (in the matlab meaning of size). Now i can do the check when evaluating the expression before trying to assign it BUT it irks me that the assert triggers inside the matrix expression evaluator instead of at the line said + was wrongly called. Could we have some way to specify code to call before returning the a new operator AST node, shoudl I overload operators myself ? Should I stick with the "assert in eval" policy and try to come up with way to tell the user which operators faile din which expression, did I miss the obvious ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] looking for an advise
On 27/12/10 11:02, Maxim Yanchenko wrote: Hi Eric and other gurus, Sorry in advance for a long post. I'm making a mini-language for message processing in our system. It's currently implemented in terms of overloaded functions with enable_if> dispatching, but now I see that Dont. this increases copiel time and provide unclear error. Accept anykind of expression adn use matches in a static_assert with a clear error ID. (a) I'm reimplementing Phoenix which is not on Proto yet in Boost 1.45.0 (that's how I found this mailing list). It would be great to reuse what Phoenix has; Isn't it in trunk already Thomas ? (b) I need to do several things on expressions and I don't know what would be the best way to approach them all. Here is a background. Every message is a multiset of named fields (i.e. is a multimap FieldName->FieldValue). I have a distinct type for each FieldName, so I can do some multiprogramming on sets of FieldNames, like making generating a structure that will hold values of the fields I need, by list of field names (e.g. fusion::map). While processing a message, I can do some checks like if particular field is present, if it's equal or not to some value, if it matches a predicate etc. They are implemented as a set of predicate functions "condition" like template< class Msg, class Expr> typename boost::enable_if< proto::matches >, bool>::type condition( const Msg& msg, const Expr& expr ) with various condition grammars in enable_if> Again, use matches inside the function body. (a) everything runs on enable_if. I expect it to become more concise and clean if I use either transforms or contexts. You need none. Put your grammar into a domain with a proper context and proto will check operators overload for you. (b) a lot of Phoenix is basically reimplemented from scratch (thanks Eric, with Proto it was very easy to do!). But I don't know how to extend Phoenix so it could work in my expressions with my things like "any_field", "optional", "mandatory" etc. Better see what Thomas has up his sleeves in Phoenix. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] phoenix 3 refactoring complete.
nice xmas present :D can't wait for the doc ;D ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto documentation, tutorials, developer guide and general Publis Relations
On 04/12/10 18:01, Eric Niebler wrote: Something along those lines would be a big improvement. I've gotten better at explaining Proto since I wrote those docs, and they could use a major facelift. I still like the fundamental idea of structuring the users guide around the idea of Proto as a compiler construction toolkit, with sections for front-end, intermediate form, and back-end. But before we get to that, there should be a Not-So-Quick Start with examples that gets people going. The structure is rather good and I (we) liked it. But some "gallery" of detailed samples could be nice to have a long-standing work-item to go through the docs and examples and The contexts must go. Great 4/ Maybe more diverse examples coudl eb turned into full fledged, detailed, step by step tutorial. map_assing map_assing? OK my dyslexia stroke again: *map_assign* Yes, this an some other newer features are not described in the users' guide at all. That includes sub-domains, per-domain control over as_child and as_expr, external transforms, and now the expanded set of functional callables. and the member<> thing or is it still in flux ? Any and all contributions are welcome. But no "assing" please. Promise ;) no assing :€ What is "this"? Are you referring to cpp-next.com? I'm pretty committed to finishing the article series I started there, and it wouldn't be right to move it elsewhere at this point. Once I sent this, I remembered abotu c++-next. Dunno if you could use it for more proto expsoure through tutorial stuff ? I wasn't asking you to move anyway :) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Proto documentation, tutorials, developer guide and general Publis Relations
Hey, recently I have been promoting Proto to a few fellow coworker in some academic circles as well as in some industrial contexts. Most of these evangelisation process turned quite well but I felt a lot of time that something wasn't clinking as it should and I think it's partially because of the way proto presents itself and how the docs examples and tutorials are structured. So here is a few remarks and some ideas on how to improve it. 1/ Proto describes itself as "Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates". A lot of people I spoke too where wondering what expression templates were and, as non-C++ expert, as honestly no clues what it was about. Others jumped on the fact that "oh it enables some lazy evaluation idiom in C++ ?". Few were acustomed to the EDSL idom. So, I wonder if we could not touch more potential users by stating it in a way "lazy evaluation" appears. 2/ What's the long term plan for context classes ? I remember discussign their removal but will it happen (at least from the doc) ? I spend quite a time demonstrating and reteaching transform over context to a lot of people. I'll gladly see them deprecated in 1.46 and maybe ditched in 1.47 or is there any reson to keep them ? 3/ The documentation on-going example of the calculator is OK but it lacks somethign between this and the full fledged, impressive small lambda or futures sampels at the end. I noticed a huge gap between the toy calculator and code people have to really write with proto. On the other hand, the Boost'con 2010 talk examples of map_assign was a real gem as it was simple enough to be grokkable by everybody and yet demonstrated a lot. I think it should be in the documentation instead of as a sample at the end. I remember thinking "why it is not detaile dlike that in the doc" during your session. 4/ Maybe more diverse examples coudl eb turned into full fledged, detailed, step by step tutorial. map_assing, some kind of simpel lazy computation stuff (like the numerical integration sampel form Veldhuizen paper), a larger example with a transform not tied to the grammar (a lot of people assumed it could not be done), etc ... Thomas Heller and I were brainstormign a bit and mayeb we can actually get a list, code it and write the tutorial over. I can also offer internals of our SIMD code or even from Quaff for a tutorial on how having proto enabled intermediate representation is useful or on how to do pattern matchign on AST. 5/ Finally, this is starting to look like the Spirit site. What about a proto blog/website where articles liek this or sample code could be detailed, introspected and published ? So here is some cents ;) Food for thought-ly yours Joel ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Externalizing grammar pattern matching
On 23/11/10 17:20, Eric Niebler wrote:
On 11/23/2010 10:19 AM, Joel Falcou wrote:
So, question is: is there a way to have an extensible list of
when that can be extended "from the outside", something
like a proto::switch_ but with patterns instead of tag ?
No. The best you can do is document how to define a new Proto algorithm
from an old one:
struct Old : proto::or_< ...> {};
struct New : proto::or_< my_stuff, Old> {};
Now everywhere in your library that you have the Old algorithm
hard-coded, you need to make it a template parameter so that your stuff
can be used with an extended algorithm.
Can't the new extrnal_transform be of any help ?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Externalizing grammar pattern matching
Here is some classical pattern matching using proto::or_ https://gist.github.com/711891 This is pretty canonical I guess (unless my proto-fu is rusting). As stated in the comments, my main concern is that adding new pattern->value rules need to edit or_<>. Also classical. For a long time it didn't bothered me until I needed to ship some code doing this AND wanting to be extended by random contributors to add new patterns. I brainstormed and conjured something like: https://gist.github.com/711895 (hold your horses on the crappiness of my MPL, it's a quick'n'dirty demo code trying to get around the fact that mpl::pair, for whatever silly reason, IS NOT a MPL RandomAccessSequence :| ) So it's slightly better. Now I dont have to touch the or_<>, just the mpl::vector. Close but no cigare. After some other hours, I found a way to make a MPL map look-a-like where the insertion is external: https://gist.github.com/711906 Alas, i can't find a way to put a decent mpl::iterator over this so both puzzles pieces fits. So, question is: is there a way to have an extensible list of when that can be extended "from the outside", something like a proto::switch_ but with patterns instead of tag ? My daydream being something akin to : https://gist.github.com/711914 So, now, I'll be grateful if you can answer this by some "you moron, use X" :D ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] : Proto transform with state
On 17/11/10 19:46, Eric Niebler wrote: See the attached code. I wish I had a better answer. It sure would be nice to generalize this for other times when new state needs to bubble up and back down. Just chiming in. We had the exact same problem in quaff where needed to carry on a process ID over the trasnform of parallel statement. If it can make you worry less Eric, we ended with the exact same workaround. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Using proto with expressions containing matrices from the EIgen library
That's a tough one :/ Main problem is probably the fact you can't control when/Where eigen do his bidding. Best shot is to externally make eigen temporary proto terminals, write a grammar that disable operators onthem and then write a transform dealing with the composite E.T AST. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
On 26/10/10 19:44, Eric Niebler wrote:
struct my_actions_with_state
{
// specializations to look up transforms
// using rules:
template
struct when;
// any ol' state can go here:
int my_state;
};
Now, you can pass an instance of my_actions_with_state as a data
parameter. Proto will use the nested "when" template to find transforms,
and your transforms can use the my_state member at runtime to do whatever.
Does that help
Oh snap ! Yes :D
Thansk for the head up
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
> You could pass it as state OK > or bundle it with the external transforms. > All you need is a nested when template. Does that help? A short example of this for my poor 7am self without coffee ;) ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
> There, that's better. I don't think I'll mess with it any more. Go ahead > and use it, Thomas. just a small question: what if I need a transform that use external data ? in nt2, we have thsi compute trnsform that recursively eats the AST and call the approprite function passing a n dimension position tuple as a data. I guess I could pass it as a state but will we have any other alternative ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
On 24/10/10 11:53, Joel de Guzman wrote: Am I the only one thinking that "actor" should be more a part of proto than phoenix? I'd love to use such a generic extension mechanism for Spirit too, for example. I *need* it for nt2 too, makes some optimisation far simpler than before. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 20/10/10 21:34, Thomas Heller wrote: On Wednesday 20 October 2010 21:24:49 joel falcou wrote: Using thomas code and my own functor class , i designed a new computation transform but it fails to dispatch. Actually it is Eric's code and idea we are using. So it is him who needs to take credit for it ;) Just so you know we fixed that. Props to the new design :) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
I took the liberty to peruse this design to redesign nt2 computation
evaluation.
As nt2 provides a lot of functions on its various DSL terminal, we're
seeking
some solution that scale - as havign 200+ case specialization is a
bit unpractical.
S, despite ppl telling me dispacthing on tag cause loss of hairs and
other
bad stuff, I came to the conclusion that I could use both part :
- dispatch on tag for most things
- dispatch on rules for local, AST based optimisation (turnign a*b+c
into madd, or similar stuff)
Using thomas code and my own functor class , i designed a new
computation transform but it fails
to dispatch. Before goign further, recall that nt2::functors::functor ae
generalized polymorphic function
object follwoing the result_of protocol. For a given tag, functor
perform the proper operation
on its arguments by forwarding the call to a call class,
Category being something
discriminating the various type i want to differentiate.
So here's the transform (reuing algorithm etc from previosu post)
template
struct bind
: boost::proto::when< Rule
, typename Actions::template action
>
{};
template
struct compiler : boost::proto::switch_ {};
//
// computation action
//
template
struct compute
{
template
struct case_
: bind< boost::proto::_
, compute
, boost::proto::tag_of()
>
{};
//
// Primary case captures any tag into appropriate functor and call it
// recursively using unpack
//
template
struct action
: boost::proto::
unpack< boost::proto::
call(compiler)>
>
{};
};
//
// Captures terminal and forward their value, state and data to the functor
//
template template
struct compute::action
: boost::proto::
call ( boost::proto::_value
, boost::proto::_state
, boost::proto::_data
)
>
{};
} }
namespace boost { namespace proto
{
template
struct is_callable > : boost::mpl::true_ {};
} }
Alas, the compiler is not happy and complain about an incompelte
proto::apply_transform type:
/usr/local/include/boost-1_44/boost/proto/transform/impl.hpp:96: error:
invalid use of incomplete type ‘struct
boost::proto::detail::apply_transform(),
nt2::simd::native
>(nt2::dsl::compilernt2::tag::sse_> > >)>(nt2::simd::packboost::proto::exprns_::is_proto_expr>&, const
nt2::simd::expressionboost::proto::argsns_::term, 0l>, float, mpl_::size_t<4u>,
boost::proto::exprns_::is_proto_expr>&, int, int)>’
/usr/local/include/boost-1_44/boost/proto/transform/impl.hpp:75: error:
declaration of ‘struct
boost::proto::detail::apply_transform(),
nt2::simd::native
>(nt2::dsl::compilernt2::tag::sse_> > >)>(nt2::simd::packboost::proto::exprns_::is_proto_expr>&, const
nt2::simd::expressionboost::proto::argsns_::term, 0l>, float, mpl_::size_t<4u>,
boost::proto::exprns_::is_proto_expr>&, int, int)>’
Thomas and me tried to fix it but not to avail ...
Before bashing me, I strongly push the fact that tag dispatching is a
valid use-case, unless
anyone can provide me with such a scalable solution without ressorting
to this.
As for a small reproductible example, it's currently a bit hard. You can
look at the code
int he nT2 github repository (github.com/jfalcou/nt2).
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] [phoenix3] New design proposal
I can imagine a lot of usecases that benefit from this feature. Let me list a few here: - Multi Stage programming: evaluate the phoenix expression to another language that can be compiled by some external compiler. The prime example i imagine for this is that someone picks that topic up, and writes a shader DSL based on phoenix reusing the already existing phoenix constructs. We already did here using a souped up phoenix like construct. SO being able to use the real thing(tm) will be even beter - Optimiziers: With the help of this Actions parameter, it almost gets trivial to write optimization passes that work on phoenix expression. I think this is worth exploring, because a optimizer working on these high level expression has way more information than for example the GIMPLE representation of GCC. see nt2 SIMD pack optimization for such use case too. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 15/10/10 09:22, Eric Niebler wrote: Goodness Joel, I have no idea what you're asking. What's the "visitor level"? Why would you have to transform the AST? What are you trying to do, exactly? LOL, please excuse my non-caeffinated post at 8am :€ I have some AST that represent arithmetic computation. I know that when I encouter a "a + b*c" node (where a,b,c can be expression themselves), I can evaluate it using an optimised call instead of chaining + and *. Currently I do this by transforming my AST into another where a+b*c is replaced by madd(a,b,c). Now, with your specialization of dispatch using grammar instead of tag, I can check for a+b*c and dispacth to a special trasnform instead of having a bloated trasnform next to that. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
Eric Niebler wrote: Dispatch to transforms on grammar rules. wait Jolly Jumper ! Does this means I could traverse a SIMD EDSL AST in search for a*b+c at the *visitor* level and not requiring to transform the AST beforehand by dispacthing over plus> ? If yes, sign me up :o ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto domains shenanigans
On 13/10/10 22:54, Eric Niebler wrote: - constant can mix with any other EDSL Make them terminals in no particular domain (proto::default_domain). Check Define a SIMD domain with no super-domain. I thought domain with no super-domain ended up in default_domain ? This sounds like you want a type system for an EDSL. Proto can't do that in its current incarnation. The hackish solution is to let everything combine with everything, capture the above rules in a Proto grammar and assert at the point of expression evaluation that the expression conforms to the grammar. Type-checking sub-expressions sometimes requires writing transforms. It's tricky. hmmm ok. I'll play and tinker with this. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Proto domains shenanigans
OK, I have a situation in which proto domain/subdomain could help me but i can't wrap my head around a proper solution. Here is the deal, i have various sub EDSL that goes like: - constants EDSL provides named consatnts (like zero_, one_, pi_ etc) that are meant to be terminal usable in any other EDSL en provide a type based way to know which constant is beging used and provide optimization in came it helps (e.g detecting x < zero_ in SIMD EDSL to replace with the SSSE3 corresponding fused operation) - a SIMD vector EDSL - various container based EDSL : table (multidim array), vector, matrix and tensor, polynom and rigid_transform. The rules I want to have is : - constant can mix with any other EDSL - SIMD don't mix with anybody - table mix with every other container and make them evaluates as table (e.g matrix * table == elementwise product and not matrix product) - vector, matrix, tensor can mix - polynom can mix with table but not with vector, matrix, tensor - rigid_transform van mix with table and matrix However i can't find any combination of domain definition that satisfy all. Is there some systematic methodologies to not fail at that ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Can't use template domain class with BOOST_PROTO_BASIC_EXTENDS
Trying to use template domain class with BOOST_PROTO_BASIC_EXTENDS
ends up in an error leading to the fact this ligne in the macro is incorrect
when the Domain is template:
BOOST_PROTO_BASIC_EXTENDS_(Expr, Derived, Domain)
typedef void proto_is_aggregate_;
typedef Domain::proto_generator proto_generator;
Obviously this is alckign a typename before Domain::proto_generator if
Domain is actually a template class.
Thing is used to work before ( aorund 1.40) so I guess somethign changed
around here.
I guess a details meta-function extracting the domain will fix that or
am I wrong ?
namespace boost { namespace proto
{
template generator_of
{
typedef typename Domain::proto_generator type;
};
} }
BOOST_PROTO_BASIC_EXTENDS_(Expr, Derived, Domain)
typedef void proto_is_aggregate_;
typedef typename generator_of::type proto_generator;
Or is it ?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 07/10/10 23:06, Eric Niebler wrote:
On 10/4/2010 1:55 PM, Eric Niebler wrote:
The idea of being able to specify the transforms separately from the
grammar is conceptually very appealing. The grammar is the control flow,
the transform the action. Passing in the transforms to a grammar would
be like passing a function object to a standard algorithm: a very
reasonable thing to do. I don't think we've yet found the right
formulation for it, though. Visitors and tag dispatching are too
ugly/hard to use.
I have some ideas. Let me think some.
Really quickly, what I have been thinking of is something like this:
template
struct MyGrammar
: proto::or_<
proto::when< rule1, typename Transforms::tran1>
, proto::when< rule2, typename Transforms::tran2>
, proto::when< rule3, typename Transforms::tran3>
>
{};
That is, you parameterize the grammar on the transforms, just the way
you parameterize a std algorithm by passing it a function object. Each
grammar (I'm thinking of starting to call Proto grammars+transforms
"Proto algorithms", because really that's what they are) must document
the concept that must be satisfied by its Transforms template parameter
(what nested typedefs must be present).
This is extremely simple and terse. It gives a simple way to extend
behaviors (by deriving from an existing Transforms model and hiding some
typedefs with your own).
I know this is not general enough to meet the needs of Phoenix, and
possibly not general enough for NT2, but I just thought I'd share the
direction of my thinking on this problem.
I've decided that th ebest way to advance this issue is to use curren
tthomas stuff in the
current nT2 development and see what use case arise from my twisted code
base and see
how it can go.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 05/10/10 08:51, Thomas Heller wrote: Having that said, just having "plain" evaluation of phoenix expressions seemed to me that it is wasting of what could become possible with the power of proto. I want to do more with phoenix expressions, let me remind you that phoenix is "C++ in C++" and with that i want to be able to write some cool algorithms transforming these proto expressions, introspect these proto expression and actively influence the way these phoenix expressions get evaluated/optimized/whatever. One application of these custom evaluations that came to my mind was constant folding, so i implemented it on top of my new prototype. The possibilities are endless: A proper design will enable such things as multistage programming: imagine an evaluator which does not compute the result, but translate a phoenix expression to a string which can be compiled by an openCL/CUDA/shader compiler. Another thing might be auto parallelization of phoenix expression (of course, we are far away from that, we would need a proper graph library for that). Nevertheless, these were some thoughts I had in mind. Not tha t far, it's basically what's my cohort of tools odes all by themselves with a clunky code base. If it get streamlined so tha i can reuse phoenix as a back end, it's just done. Period. We already have the openCL things working and running and even out performing commercial product ... We just need a proper code base ;) As far as my memories go, we abandoned those prototypes because of several reasons, one was that this early prototype was quite complex and not very easy to follow, i guess this is true for my attempt to resurrect it. The other thing was that people felt like we exposed too much of proto to users who wanted to extend phoenix. Last but least, it differed too much from the design of phoenix2. See my explanations above on my try to tackle the criticism on all these points. It didn't exposed tha much proto ... unless you consider proto::_ to be too much :/ And back in the day, I didn't knew making the new phoenix a clone of the old was a design requirements ;) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 04/10/10 20:45, Eric Niebler wrote: I'm not opposed to such a thing being in Proto, but I (personally) don't feel a strong need. I'd be more willing if I saw a more strongly motivating example. I believe Joel Falcou invented something similar. Joel, what was your use scenario? NT2 ;) More specifically, all our transform are built the same way: visit the tree, dispatch on visitor type + tag and act accordignly. It was needed for us cause the grammar could NOT have been written by hand as we supprot 200+ functions on nt2 terminal. All our code is somethign like "for each node, do Foo" with variable Foo depending on the pass and duplicating the grammar was a no-no. We ended up with somethign like this, except without switch_ (which I like btw), so we can easily add new transform on the AST from the external view point of user who didn't have to know much proto. As I only had to define one grammar (the visitor) and only specialisation of the visitor for some tag, it compiled fast and that was what we wanted. Thomas, why not showign the split example ? It's far better than this one and I remember I and Eric weren't able to write it usign grammar/transform back in the day. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
On 16/08/10 23:46, Daniel Oberhoff wrote: ha, its alive :) Getting it out is my main priority for 2010. did you get my query as to wether it will be possible to get sse acceleration without having to specify it in the type or having sizes be divisible by four (or even satisfying alignment provably at compile time)? Now compiling with -msse2 is enough to trigger simdisation. If you use nt2 container it does everythign already (alignment+padding). If you happen to pass some naked pointer, we have a split strategy: we ofund the first aligned element, the last one and apply SSE on these. The pre and prologue are done in a scalar way. That's the best we can do. To prevent further pollution of this ML, I direct you to http://groups.google.com/group/nt2-dev btw, should I find time I am happy to help. No problem :) Soon, the git will contain the bare container system based on proto with a selection of usable functions. Tests and deploiement will be very welcome. also you might be interested in checking out cuda thrust with regard to dispatch to openmp and cuda (and with the help of the ocelot project also to other opencl devices): We have a post-doc on that already. Current prototype for openCL based nt2 is on the par with comemrcial product liek Rapidmind. (Sorry eric for this hijacking) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
On 16/08/10 23:30, Daniel Oberhoff wrote: I am still dreaming of a numeric library with a blitz like interface that dispatches automatically (with both static and dynamic dispatch as appropriate) to serial, sse, openmp-style, and cuda code. Follow http://github.com/jfalcou/nt2 in the upcoming months then ;) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
Got some error trying to compile this vs boost :: trunk j...@dell-desktop:~/Desktop$ time g++-4.3 -O3 -c options.cpp -I./ -I/usr/local/include/boost-trunk options.cpp: In member function ‘typename boost::option_expr::result ()(Option, Default)>::type boost::option_expr::operator()(const Option&, const Default&) const’: options.cpp:103: error: wrong number of template arguments (3, should be 2) /usr/local/include/boost-trunk/boost/proto/proto_fwd.hpp:435: error: provided for ‘template struct boost::proto::matches’ /usr/local/include/boost-trunk/boost/mpl/assert.hpp: At global scope: /usr/local/include/boost-trunk/boost/mpl/assert.hpp: In instantiation of ‘mpl_::assert_arg_pred_not’: options.cpp:103: instantiated from here /usr/local/include/boost-trunk/boost/mpl/assert.hpp:148: error: ‘int’ is not a class, struct, or union type /usr/local/include/boost-trunk/boost/mpl/assert.hpp:149: error: ‘int’ is not a class, struct, or union type ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
On 15/08/10 23:21, Eric Niebler wrote: Haha! I admit I was a bit suspicious at first. Nobody ever said, "Wow, Proto sped up my compiles!" ;-) I wish :) But looking at Joel's implementation, I suspect it can be sped up considerably by avoiding fusion vectors and maps. (I've found fusion to be costly at compile time and generally avoid it in Proto.) Yup, same experience here. I dunno if it comes fromthe TMP part of the PP part tough I don't see a reason why the proto expression tree can't directly serve the same role as the fusion map. Just define a transform instead of using fusion::at_key. Hmmm, how should this transform work ? We already capture the value of the parmaeters by value in the tree so it can actually be used for this but I admit the transform is not trivial. Regardless, a nifty hack, and amazing you could do this in a few hours. It was the point of the game ;) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
On 15/08/10 20:21, Daniel Wallin wrote: So you implemented something significantly slower (3 times on machine with gcc4.3). Not very surprising; adding complex abstraction in the implementation rarely makes things faster. As I said, it's more of an exercice than anything else. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
Code is now uplaoded to some GIT repo: http://github.com/jfalcou/boosties/ ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
On 15/08/10 17:46, Tim Moore wrote: Nice. I've been meaning to start using Boost.Parameter in one of my projects but I definitely like this syntax better. I'll probably start using this soon (like this week). Please post if you make updates. Thanks for the interest.It's still in its infancy and lack some of the features of boost::parameters. I'll prolly put up a boost git on my account and put it inside in a proper form. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Funky exercie: subset of Boost::parameters using proto
So, Thomas and I felt bored or some suhc this afternoon. Incidentally, I needed to use Boost::Parameters in NT² but found the compile time to be somehow slow. So in a flash of defiance, we went to reimplementing a subset of parameters using proto. The syntax is ratehr different but the effect is ratehr nice. The code is here: http://gist.github.com/525562 Comments welcome ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
> This is kind of like Proto's evaluation contexts, IIUC. I'm not wild for > them because often just the tag isn't enough information to find the > right handler. But maybe it covers enough use cases and can be made > easier to use. Right now, proto has an "eval" function that takes an > expression and an evaluation context, but the user is responsible for > the flow control. Maybe there should be a pre_order_eval and > post_order_eval that takes on the control flow responsibilities. Yes but here each tag specialization leaves in its own function object and not as an operator()(). For sepcific need, we can specialize based on tag+type of visitor+type of "visitee". > Tags don't have arities. E.g. nothing prevents someone from creating an > expression with tag::plus and 5 children. Yes but the same way proto operator has the expected behavior by defualt, one can expect they have expected arity. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 11/08/10 17:52, Eric Niebler wrote: I don't exactly recall the details of Joel's technique. My experiments to separate transforms from grammars were largely unsuccessful because control flow often need pattern matching. I'd like to see alternate designs. Mine was just a post-order traversal by a visitor that could be specialized on node's tag Ah, but the control flow of this transform depends on pattern matching (i.e., the grammar) to dispatch to the correct handler. I'm interested to see what this arity calculation would look like with a tree traversal. Last time I tried, i ended up needing a meta-function that gave you the arity of any tag. Then you did a fold of max over the tree traversal. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 11/08/10 09:53, Thomas Heller wrote: Joel Falcou showed a technique which, to some extend is able to deal with the no-repetition part. Fact is that I just play on the fact Transform X can be applied one xpression buitl on Grammar Z, Z and X being unrelated. We use that quite a lot in our EDSL. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
> Good. Now if you are saying that Proto's existing transforms are too > low-level and that things like pre- and post-order traversals should be > first class Proto citizens ... no argument. Patch? :- Yup exactly as soon as i haver a real kboard ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
I'm on a tiny mobile, but my idéa was to have such algo as proto transforms & grammar > On 8/10/2010 4:48 AM, Gordon Woodhull wrote: >> Thanks Joel, >> >> This is food for thought! > > Indeed, but I'm struggling to keep up because I don't really know what > you guys are after. > >> On Aug 10, 2010, at 2:47 AM, joel falcou wrote: >>> On 10/08/10 05:24, Gordon Woodhull wrote: >>>> >>>> I wonder if Dan Marsden's Traversal library would solve this out of >>>> the box? >>>> http://boost-spirit.com/dl_docs/traversal/html/traversal/introduction.html >>> >>> Oh nice link, I didn't knew that :o >>> >>>> The way I would solve it is to create an adapter that makes a Proto >>>> tree look like a graph... Like Boost.Graph, Metagraph is designed to >>>> allow adapting any metadata that is already graphlike to have a graph >>>> API. (This wasn't the right approach for MSM because there's nothing >>>> in those tables that immediately answers "what are the edges for this >>>> vertex?") >>>> >>>> If there is interest, > > There is! I think. What is the goal? To be able to apply graph > algorithms to Proto expressions? Why, exactly? Turning an expression > tree into a graph seems like a step backward to me. Trees are easier to > process than graphs, IIUC. Where have I gone astray? > >>>> I could probably pull this together pretty >>>> quickly, as Proto already has such an expressive API. Then we'd >>>> immediately have inefficient implementations of DFS & BFS and I could >>>> see if there's a good way to factor out the color map stuff to make >>>> it speedy. >>> >>> We're looking at two challenge in Proto : >>> -> traversing the AST type at compile-time to apply meta-function onto >>> tree node > > Above and beyond what you get by using Proto grammars+transforms? > >> I just committed an example which does this part. See end of message. > > Committed where? > >>> -> traversing the AST value at run-time to apply function onto tree >>> node > > Again, this is what Proto grammars+transforms are for. If they're not > doing the job, let's talk about why. > >> This requires a Fusion/BGL interface, which I haven't thought out yet. >> Probably just means moving a parameter from the <> to () as usual. :-D > > IIUC, BGL has a homogeneous interface, like the STL. I don't think you > can get it to play well with Fusion, or Proto for that matter. > >>> for example here is my current use-cases: >>> >>> - walkign through a proto AST to apply a visitor onto node/leaf : turn >>> the AST on array into the same AST with pointer element before >>> evaluation >> >> Yes, I imagine that's the most common use case. How hard can that >> Fusion/BGL interface be? > > I can do this easily with a Proto grammar w/ transform. > >>> - turning the AST into a DAG >> >> Yay! > > Use case? > >> Stjepan Rajko and I talked about doing this in order to allow Proto >> expressions to define graph metadata. >> >> Maybe you'd kind of cut and paste the Proto tree into an mpl graph while >> looking for vertices with duplicate IDs. Should work just as well on >> graphs with cycles. >> >> This way you'd end up with sort of a graph metadata overlay over the >> Proto tree. Each vertex would contain metadata instructions for how to >> get to the corresponding Proto node in the expression, and each edge >> would be vertex+child#. No extra runtime data needed, if I'm not >> mistaken. >> >> You could also imagine doing this with a Fusion graph somehow, if you >> wanted to add runtime data... but I don't grok the Fusion/Proto >> allocation/reference magic yet, so I'm not quite sure what I'm saying. > > I can speak to Proto's allocation/reference magic. There is no (dynamic) > allocation. By default, everything is held by reference, even > intermediate temporary expressions. The default can be changed and > things can be held by value. There's also a deep_copy function to turn > references into values. > > Proto is not built on top of Fusion. There is an adaptor layer, but it > doesn't fit too well at the moment; heterogeneous trees are hard until > Fusion gets complete segmented iteration support, and I'm not 100% > convinced that's the way forward (see iterators vs. vi
Re: [proto] So I heard proto make AST ...
On 10/08/10 05:24, Gordon Woodhull wrote: Sorry for the slow response - been on vacation offline. No problem ;) I wonder if Dan Marsden's Traversal library would solve this out of the box? http://boost-spirit.com/dl_docs/traversal/html/traversal/introduction.html Oh nice link, I didn't knew that :o The way I would solve it is to create an adapter that makes a Proto tree look like a graph... Like Boost.Graph, Metagraph is designed to allow adapting any metadata that is already graphlike to have a graph API. (This wasn't the right approach for MSM because there's nothing in those tables that immediately answers "what are the edges for this vertex?") If there is interest, I could probably pull this together pretty quickly, as Proto already has such an expressive API. Then we'd immediately have inefficient implementations of DFS & BFS and I could see if there's a good way to factor out the color map stuff to make it speedy. We're looking at two challenge in Proto : -> traversing the AST type at compile-time to apply meta-function onto tree node -> traversing the AST value at run-time to apply function onto tree node The main API debate when it comes to traversals is "visitors or iterators?" Currently metagraph takes the visitor approach from Boost.Graph, which are more general and expressive, but iterators are often more convenient. Any opinions here? AFAIK we don't have coroutines or continuations in C++ metaprogramming to make the inversion of control easier. ;-) I can't say much but, for example here is my current use-cases: - walkign through a proto AST to apply a visitor onto node/leaf : turn the AST on array into the same AST with pointer element before evaluation - turning the AST into a DAG - applying a visitor performing osme kind of reduction on the tree startign form the leaf to evaluate the value of the AST in a given point of evaluation - for a given assign node (lhs = rhs) check if the lhs data address is somewhere in the terminal of rhs. This is basically our trickiest runtime algorithm in nt2 that helps us detetcing alias in expression without having ppl using alias(x) function. - detecting pattern in the AST (like a+b*c) and repalce all of them, recurisvely into another (here by madd(a,b,c)). It's currently done with special grammar and it's maybe better to do it like this but we never know. I'm from the old guard w/r to tree, so I'm mostly thinking in visitor. But if you care to show me how iterators can be used, I'm open to suggestion. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto v4.1
On 04/08/10 19:42, Eric Niebler wrote: IIRC, you use some tricks to bring down compile times, right? I think that would make a very good section for the docs, yes. Basically: - using make_expr instead of function objetc made CT linear instead of quadratic - swicth and other stuff to keep grammar type "small" helped too I'll write some stuff. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto v4.1
On 04/08/10 01:00, Eric Niebler wrote: Most folks here don't know this, but the version of Proto y'all are using is actually v4. (Three times the charm wasn't true for Proto.) Anyway, there are so many goodies coming in Boost 1.44 that think of it as Proto v4.1. I just posted the release notes for this version to give you guys an heads-up of the coming changes. There are a few very small breaking changes that you should take careful note of. Most of the interesting stuff is in the new features: sub-domains and per-domain control of as_expr and as_child. Have a look. Let me know if you have any questions: Boost 1.44 release notes: http://tinyurl.com/242ln7f FYI, most of these changes were motivated by the Phoenix3 work. That sure is one demanding DSEL. Would you like me to write some lines on my compile-time performance and figures to include somewhere in the doc. I remember you wanted to do that at some point. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:56, Alp Mestanogullari wrote: On Tue, Jul 27, 2010 at 3:25 PM, joel falcou wrote: I do this in NT2 all the time IIRC I gave a link to some svn repo with an example. It wasn't selected as core phoenix 3 though :p Yeah I remember discussing that code with you on IRC, and this is an elegant and very "functional" approach, I like it! But it's just my opinion. Foudn it back, ppl may look at : https://www.lri.fr/svn/parall/prog_gen/branches/phoenix3/ login/passwd : boost/boost The code is just a proto transform that evaluate any kind of expression and values from a fusion vector in a recursive, customizable way. I think it can be turned into a proper proto::dfs_visitor<> transform ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:21, Alp Mestanogullari wrote: Yeah definitely. They would just have to provide the node transform, and you would just forward it to the tree traversal metafunction. Quite straight for an extension mechanism! I do this in NT2 all the time IIRC I gave a link to some svn repo with an example. It wasn't selected as core phoenix 3 though :p ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:15, Christophe Henry wrote I think you should talk to Gordon Woodhull. He's building a metagraph (among others) library, which I am going to use in msm for compile-time calculations and fsm analysis. This means there will be temporarily a metagraph library inside msm as proof of concept until there can be a review. Maybe he can adapt this library for proto analysis? Oh yeah, will save me some time indeed. Mayeb we shoudl invite him over here ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:08, Eric Niebler wrote: That would be awesome, Joel! WHat's the easiest in term of code ? I can bring up some git repo or shoudl I work in some svn branches of proto somewhere at boost ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:08, Eric Niebler wrote: That would be awesome, Joel! I'll count on you for helping me making those looking nice :p What's the easiest ? getting a proto-tree branch or what ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] So I heard proto make AST ...
what about having some Tree related trasnform/function/meta-function then ? I'm often thinking : "dang, this transform is basically a BFS for a node verifying meta-function foo<>" and have to rewrite a BFS usign default_ and such, which is relatively easy. Now, sometimes it is "dang, this code is basically splitting an AST into multiples AST everytime I found a bar tag" or "I need to do a DFS" or even worse, I need to make the AST a DAG :E ... Do people think such stuff (maybe in proto::tree:: or smthg ?) be useful additions ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
