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? _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto