|
|
Proto : |
Subject: Re: [proto] So I heard proto make AST ...
From: Eric Niebler (eric_at_[hidden])
Date: 2010-08-11 14:18:56
On 8/11/2010 2:03 PM, Joel.Falcou_at_[hidden] wrote:
>> 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()().
The most general form of a proto context has a nested eval class
template that are function objects specialized on ... tag type! Only
"callable" contexts use operator()() overloads as a convenience. You
should look into it and tell me whether that meets your needs, or if you
think this mechanism can/should be extended.
> For sepcific need, we can specialize based on tag+type of visitor+type of
> "visitee".
This is giving me bad flashbacks to Proto v1 and its "compilers". These
let you customize a tree transform by specializing templates based on
"tag" and "domain". Very primitive. It became contexts, which became
transforms. I'm attaching the original docs for Proto v1's compilers,
which at this point are nothing more than a historical curiosity. But
you should see that I've explored many of these ideas already and
abandoned them.
>> 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.
Yes, and there's some precedence for this in Proto ... e.g., the
_default grammar+transform will only accept those expressions that make
sense in standard C++. But I'd like to limit it to that. A general
purpose tree visitation mechanism should not attach *any* semantic
weight to the tags. They're just tags.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Proto list run by eric at boostpro.com