On 10/22/2010 8:53 AM, Eric Niebler wrote:
On 10/21/2010 12:13 PM, Joel de Guzman wrote:
Do you mean that it has to be exactly that to be called a "visitor"?
How exact? Does it have to be "an OO hierarchy with a virtual "Dispatch"
member that accepts a visitor"?
No, there's some wiggle room.
On 10/21/2010 12:13 PM, Joel de Guzman wrote:
>
> Do you mean that it has to be exactly that to be called a "visitor"?
> How exact? Does it have to be "an OO hierarchy with a virtual "Dispatch"
> member that accepts a visitor"?
No, there's some wiggle room. I tried to state in a latter message wh
On 10/21/10 11:11 AM, Eric Niebler wrote:
On 10/20/2010 7:49 AM, Thomas Heller wrote:
I worked a little on trying to simplify that whole grammar with
rules that have thing a bit. Forgive me, but i changed the name to Visitor.
Why? Simply because i think this is what is done here. We visit a spec
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
ta
On 10/20/2010 11:41 PM, Thomas Heller wrote:
> On Thu, Oct 21, 2010 at 7:50 AM, Thomas Heller
> wrote:
>> On Thursday 21 October 2010 05:11:49 Eric Niebler wrote:
>>> On 10/20/2010 7:49 AM, Thomas Heller wrote:
>
Here it goes:
namespace detail
{
template <
On Thu, Oct 21, 2010 at 7:50 AM, Thomas Heller
wrote:
> On Thursday 21 October 2010 05:11:49 Eric Niebler wrote:
>> On 10/20/2010 7:49 AM, Thomas Heller wrote:
>> > Here it goes:
>> > namespace detail
>> > {
>> >
>> > template <
>> >
>> > typename Grammar, typename Vis
On Thursday 21 October 2010 05:11:49 Eric Niebler wrote:
> On 10/20/2010 7:49 AM, Thomas Heller wrote:
> > I worked a little on trying to simplify that whole grammar with
> > rules that have thing a bit. Forgive me, but i changed the name to
> > Visitor. Why? Simply because i think this is what is
On 10/20/2010 7:49 AM, Thomas Heller wrote:
> I worked a little on trying to simplify that whole grammar with
> rules that have thing a bit. Forgive me, but i changed the name to Visitor.
> Why? Simply because i think this is what is done here. We visit a specific
> node which happened to match
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 ;)
___
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 ca
On Wednesday 20 October 2010 15:02:01 Eric Niebler wrote:
> On 10/14/2010 12:27 PM, Eric Niebler wrote:
>
>
> > - A new set of actions can be created easily by delegating
> >
> > to MyActions::action by default, and specializing only those
> > rules that need custom handling.
>
> The code I
On 10/14/2010 12:27 PM, Eric Niebler wrote:
> - A new set of actions can be created easily by delegating
> to MyActions::action by default, and specializing only those
> rules that need custom handling.
The code I sent around actually falls short on this promise. Here's an
updated design that
> >> Let me add here, that i am planning on writing a boost.wave driver
> >> which allows to preprocess headers (as MPL already does), expanding
> >> BOOST_PP iteration constructs until a certain N. I believe this kind
> >> of preprocessing will bring down compile times of proto, fusion and
> >> ph
On Saturday 16 October 2010 04:10:23 Eric Niebler wrote:
> On Thu, Oct 14, 2010 at 10:46 PM, Thomas Heller
>
> wrote:
> > So, one of your points of criticism was that my solution was overly
> > verbose.
> > I like to throw this ball back at you. I think both solutions are quite
> > verbose. I gues
On 10/17/2010 6:51 AM, Eric Niebler wrote:
Let me add here, that i am planning on writing a boost.wave driver which
allows to preprocess headers (as MPL already does), expanding BOOST_PP
iteration constructs until a certain N. I believe this kind of preprocessing
will bring down compile times of
On 10/14/2010 4:46 AM, Eric Niebler wrote:
On 10/13/2010 11:54 AM, Thomas Heller wrote:
I don't get that. There needs to be a phoenex grammar. One, and only
one. I don't see why it's a template, what the tag type is for, or how
one could use a tag to define a "better" phoenix grammar. Because
On 10/5/2010 3:43 AM, Thomas Heller wrote:
On Mon, Oct 4, 2010 at 8:45 PM, Eric Niebler wrote:
On 10/4/2010 6:49 AM, Thomas Heller wrote:
Hi,
I spent some time on thinking how one could make the traversal of a proto
expression tree easier. I know want to share my findings with you all, and
pr
On 10/16/2010 12:15 PM, Thomas Heller wrote:
> On Saturday 16 October 2010 03:45:45 Eric Niebler wrote:
>> On Fri, Oct 15, 2010 at 1:35 AM, Thomas Heller
>>
>> wrote:
>>> On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
I had a really hard time grokking unpack. In Proto, function-type
On Saturday 16 October 2010 03:45:45 Eric Niebler wrote:
> On Fri, Oct 15, 2010 at 1:35 AM, Thomas Heller
>
> wrote:
> > On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
> > > I had a really hard time grokking unpack. In Proto, function-types
> > > are used to represent function invocatio
On Thu, Oct 14, 2010 at 10:46 PM, Thomas Heller
wrote:
> So, one of your points of criticism was that my solution was overly
> verbose.
> I like to throw this ball back at you. I think both solutions are quite
> verbose. I guess verbosity is what it takes to get a solution meeting the
> requiremen
On Fri, Oct 15, 2010 at 1:23 AM, joel falcou wrote:
> 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-caef
On Fri, Oct 15, 2010 at 1:35 AM, Thomas Heller
wrote:
> On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
> > I had a really hard time grokking unpack. In Proto, function-types are
> > used to represent function invocation and object construction. The type
> > "X(A,B,C)" means either call
On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
> On 10/4/2010 11:51 PM, Thomas Heller wrote:
> > Eric Niebler wrote:
> >> On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
> >Note: i created a unpack transform which is boilerplate code for the
> >
> > extraction of the c
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 co
On 10/14/2010 11:04 PM, Joel Falcou wrote:
> 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 ove
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
_
Eric Niebler wrote:
> On 10/13/2010 11:08 PM, Thomas Heller wrote:
>> Let me try again ...
>> I tried to solve the problem that when writing a proto grammar+transform
>> you might want to dispatch your transform based on tags.
>
> You mean expression tags, right? First time I read this, I accepte
On 10/13/2010 11:08 PM, Thomas Heller wrote:
> Let me try again ...
> I tried to solve the problem that when writing a proto grammar+transform you
> might want to dispatch your transform based on tags.
You mean expression tags, right? First time I read this, I accepted this
statement as fact. No
On Thursday 14 October 2010 08:29:00 Eric Niebler wrote:
> On 10/13/2010 11:08 PM, Thomas Heller wrote:
> > On Wednesday 13 October 2010 22:46:40 Eric Niebler wrote:
> >> On 10/13/2010 11:54 AM, Thomas Heller wrote:
> >>> On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
> >
> > See my oth
On 10/13/2010 11:08 PM, Thomas Heller wrote:
> On Wednesday 13 October 2010 22:46:40 Eric Niebler wrote:
>> On 10/13/2010 11:54 AM, Thomas Heller wrote:
>>> On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
>
> See my other post about comments on this, I think we agree on the rest.
> The o
On Wednesday 13 October 2010 22:46:40 Eric Niebler wrote:
> On 10/13/2010 11:54 AM, Thomas Heller wrote:
> > On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
> >> Possibly. But now, you're explicitly constructing a terminal with a
> >> reference_wrapper as a value. Proto doesn't know how t
On Thursday 14 October 2010 01:58:16 Eric Niebler wrote:
> On 10/4/2010 12:20 PM, Thomas Heller wrote:
> > On Mon, Oct 4, 2010 at 8:53 PM, joel falcou wrote:
> Joel, I don't recall this particular problem or being unable to solve it
> with Proto transforms.
>
> > The split example was one of the m
On Wednesday 13 October 2010 22:46:40 Eric Niebler wrote:
> On 10/13/2010 11:54 AM, Thomas Heller wrote:
> > On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
See my other post about comments on this, I think we agree on the rest.
The only problem we are diverging right know seems to be th
On 10/4/2010 12:20 PM, Thomas Heller wrote:
> On Mon, Oct 4, 2010 at 8:53 PM, joel falcou wrote:
>> 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 motiv
On 10/13/2010 11:54 AM, Thomas Heller wrote:
> On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
>> Possibly. But now, you're explicitly constructing a terminal with a
>> reference_wrapper as a value. Proto doesn't know how to treat
>> reference_wrapper when evaluating Phoenix expression be
On Wednesday 13 October 2010 20:15:55 Eric Niebler wrote:
> On 10/12/2010 11:06 PM, Thomas Heller wrote:
> > On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
> >> On 10/4/2010 11:51 PM, Thomas Heller wrote:
> >>> During the last discussions it became clear that the current design
> >>> was
On 10/12/2010 11:06 PM, Thomas Heller wrote:
> On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
>> On 10/4/2010 11:51 PM, Thomas Heller wrote:
>>> During the last discussions it became clear that the current design
>>> wasn't as good as it seems to be, it suffered from some serious
>>> lim
On Wednesday 13 October 2010 07:10:15 Eric Niebler wrote:
> On 10/4/2010 11:51 PM, Thomas Heller wrote:
> > Eric Niebler wrote:
> >> On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
> >
> >> wrote:
> >
> >
> I'll also point out that this solution is FAR more verbose that the
> original w
On Tuesday 12 October 2010 22:24:25 Eric Niebler wrote:
> On 10/4/2010 10:57 PM, Thomas Heller wrote:
> > Eric Niebler wrote:
> >> On 10/4/2010 12:20 PM, Thomas Heller wrote:
> >>> the new thing i added is transform_expr, which works like
> >>> fusion::transform: It creates the expression again, wi
On Tuesday 12 October 2010 22:37:06 Eric Niebler wrote:
> On 10/12/2010 1:24 PM, Eric Niebler wrote:
> > So it really seems to me that transform_expr is not necessary, but I
> > may be wrong.
>
> I just confirmed this by trivially replacing uses of transform_expr with
> appropriate uses of nary_ex
On 10/4/2010 11:51 PM, Thomas Heller wrote:
> Eric Niebler wrote:
>
>> On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
>> wrote:
>
>>>
I'll also point out that this solution is FAR more verbose that the
original which duplicated part of the grammar. I also played with such
visi
On 10/12/2010 1:24 PM, Eric Niebler wrote:
> So it really seems to me that transform_expr is not necessary, but I may
> be wrong.
I just confirmed this by trivially replacing uses of transform_expr with
appropriate uses of nary_expr in your phoenix_test.cpp (attached).
The only difference is the
On 10/4/2010 10:57 PM, Thomas Heller wrote:
> Eric Niebler wrote:
>> On 10/4/2010 12:20 PM, Thomas Heller wrote:
>>> the new thing i added is transform_expr, which works like
>>> fusion::transform: It creates the expression again, with transformed
>>> child nodes (the child nodes get transformed ac
Eric Niebler wrote:
> On 10/8/2010 12:12 AM, Thomas Heller wrote:
>> On Thursday 07 October 2010 23:06:24 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 gra
On 10/8/2010 12:12 AM, Thomas Heller wrote:
> On Thursday 07 October 2010 23:06:24 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
>>> flo
On Thursday 07 October 2010 23:06:24 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 tra
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 woul
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
On 10/4/2010 11:51 PM, Thomas Heller wrote:
> On Tuesday 05 October 2010 03:15:27 Eric Niebler wrote:
>> I'm looking at this code now, and perhaps my IQ has dropped lately
>> (possible), but I can't for the life of me figure out what I'm looking
>> at. I'm missing the big picture. Can you describe
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 wit
Eric Niebler wrote:
> On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
> wrote:
>>
>> >
>> > I'll also point out that this solution is FAR more verbose that the
>> > original which duplicated part of the grammar. I also played with such
>> > visitors, but every solution I came up with suffered from
Eric Niebler wrote:
> On 10/4/2010 12:20 PM, Thomas Heller wrote:
>> On Mon, Oct 4, 2010 at 8:53 PM, joel falcou
>> wrote:
>>> 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
On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
wrote:
> On Mon, Oct 4, 2010 at 8:45 PM, Eric Niebler wrote:
> > On 10/4/2010 6:49 AM, Thomas Heller wrote:
> >> Hi,
> >>
> >> I spent some time on thinking how one could make the traversal of a
> proto
> >> expression tree easier. I know want to sha
On Mon, Oct 4, 2010 at 8:45 PM, Eric Niebler wrote:
> On 10/4/2010 6:49 AM, Thomas Heller wrote:
>> Hi,
>>
>> I spent some time on thinking how one could make the traversal of a proto
>> expression tree easier. I know want to share my findings with you all, and
>> propose a new addition to proto.
On 10/4/2010 12:20 PM, Thomas Heller wrote:
> On Mon, Oct 4, 2010 at 8:53 PM, joel falcou wrote:
>> 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
>>> motiv
On Mon, Oct 4, 2010 at 8:53 PM, joel falcou wrote:
> 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 somet
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 ;)
Mor
On 10/4/2010 6:49 AM, Thomas Heller wrote:
> Hi,
>
> I spent some time on thinking how one could make the traversal of a proto
> expression tree easier. I know want to share my findings with you all, and
> propose a new addition to proto.
>
> My first idea was to decouple grammars from transfor
58 matches
Mail list logo
