- From: Christian de Sainte Marie <csma@ilog.fr>
- Date: Tue, 17 Mar 2009 15:01:23 +0100
- To: Gary Hallmark <gary.hallmark@oracle.com>
- CC: Dave Reynolds <der@hplb.hpl.hp.com>, Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Gary Hallmark wrote: > Too much sugar leads to bloat and rot. It's not very good for language > design either :-) > > This has been Christian's pet PRD feature for so long, I've grown tired > of arguing about it. :-) > I think all the dialects, PRD included, can do without this sugar. I > prefer treating all the conditions uniformly, i.e. > Forall (x) Q :- P AND C(x) </chair> Except that, for very obvious extensions of PRD, it is not only sugar... Let me repeat why I support it: - OMG PRR has it, and most PR languages have it, and the ordering of variable bindings that comes with it, and having them in RIF too makes translation to?from PRD easier (and the binding patterns and their ordering may have a huge impact on performance, so, it contains information, although non-semantic one); - Bounded variables will be required as soon as we add an "else" part; - addtionally, the binding formula will be the natural place to add a "from" feature. Now, a different motivation might be that it might make the safeness condition in Core easier to specify, because it applies to the binding formula only, where we can place restrictions on the number of unbound variables etc. The reason why Forall are nested in PRD is, precisely, because it allows ordering the variable bindings, and we could easily require, for instance, that no binding formula binds more than one variable; and, even, that the binding formulas are ordered, in the sense that all the variables ina binding formula are bound but one, e.g.: Forall x in C(x), Y in C(x, y), z in C(x, y, z), If ... Now, all this being said: yes, at this stage, this is merely syntactic sugar, as far as I can see; and the non-semantic info about ordering etc could go into annotations. <chair> Christian
Received on Tuesday, 17 March 2009 14:02:33 UTC