Proto for Boost mailing list page: Re: [proto] grammars, domains and subdomains

Subject: Re: [proto] grammars, domains and subdomains
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-12-09 10:51:55

Eric Niebler wrote:

> On 12/8/2010 5:30 PM, Thomas Heller wrote:
>> I don't really now how to do it otherwise with the current design.
>> There is really only this part of the puzzle missing. If it is done, we
>> have a working and clean Phoenix V3.
>> For the time being, I can live with the workaround I did.
>> However, I will focus my efforts of the next days on working out a patch
>> for this to work properly.
> 
> I made a simple fix to proto::matches on trunk that should get you
> moving. The overloads can still be smarter about sub-domains, but for
> now you can easily work around that by explicitly allowing expressions
> in sub-domains in your super-domain's grammar. See the attached solution
> to your original problem.

It solves the problem as it succeeds to compile.
However, there are two problems with that solution:
  1) t2 is matched by grammar1
  2) I have to add the plus rule in grammar2 (this could be solved with the 
     grammar parametrisation from my earlier post)
  3) The expression in a subdomain is matched in grammar1 on the pure fact 
     that it is a subdomain of domain1, it should be matched against the 
     subdomains grammar as well.

Right now, i am questioning the whole deduce_domain domain part and
selection of the resulting domains in proto's operator overload.
Here is what i think should happen (Without the loss of genericity I
restrict myself to binary expressions):

If the two operands are in the same domain, the situation is clear:
The operands need to match the grammar belonging to the domain, and the
result has to as well.

If one of the operands is in a different domain the situation gets
complicated. IMHO, the domain of the resulting expression should be
selected differently.
Given is a domain (domain1) which has a certain grammar (grammar1) and
sub-domain (domain2) with another grammar (grammar2).
When combining two expressions from these domains with a binary op, the
resulting expression should be in domain2.
Why? Because there is no way that when writing grammar1 to account the
expressions which should be valid grammar2. With the current deduce_domain,
this is determined to fail always. Additionally, conceptionally, it makes
no sense that a expression containing t1 and t2 be in domain1.
When the domains are not compatible (meaning they have no domain - sub
domain relationship), the resulting domain should be common_domain.

These considerations are based on the assumption that a expression in a
sub-domain should not be matched by the grammar of the super domain.
Which makes sense, given the context of the local variables in phoenix.
Remember, local variables shall only be valid when embedded in a let or
lambda expression.
Maybe, the sub-domain idea is not suited at all for that task.

OK ... thinking along ... The stuff which is already in place, and your
suggested fix, makes sense when seeing sub-domains really as extensions to
the super domain, and the grammar of these ...

Thoughts?