- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Tue, 19 May 2009 11:52:38 -0400
- To: Chris Welty <cawelty@gmail.com>
- Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
see within... On Tue, 19 May 2009 08:44:43 -0400 Chris Welty <cawelty@gmail.com> wrote: > Michael Kifer wrote: > > Chris, > > thanx for your thoughts. This is useful and maybe we can converge soon. > > Pls see below. > > > > On Mon, 18 May 2009 23:01:40 -0400 > > Chris Welty <cawelty@gmail.com> wrote: > > > >>>> Common Logic allows variable symbols and constant symbols to overlap. Do the > >>>> subsets need to be disjoint? All these types of things can be distinguished > >>>> by their syntactic context. > >>> This is just an unnecessary complication, which buys you nothing. > >>> In many respects, RIF is more general than Common Logic, and forcing one to > >>> decide what is a variable and what isn't by the context is a huge nuisance. > >>> In fact, you CANNOT determine what is a variable by the context alone. > >>> Many rule languages omit quantifiers. How do you distinguish then? > >> As you point out below, the choice should be up to a dialect. Allowing variable > >> and constant symbols to overlap in FLD simply means that a dialect can make that > >> choice, not that every dialect must support it. As it is, Common Logic cannot > >> be expressed as an FLD dialect, and thus it is not more general. > > > > FLD is a framework for exchange languages. An exchange language is a common > > medium to which other languages are mapped. Are you saying that Common Logic > > cannot be mapped to FLD? I don't believe it until you prove it. Good > > luck! :-). > > Its not Fermat's last theorem, but here goes: > Common logic allows variable names and constant names to overlap. FLD does not > allow a dialect to do this. Common Logic cannot be a dialect of FLD. QED. Lousy job :-) I said prove that CL can't be *mapped* to a suitable FLD dialect. CL "can't be a dialect" for much more obvious reasons than your pseudo-theorem "proves." Simply: it has a different syntax, so it is not a dialect. But a suitable dialect is one that allows a simple mapping of CL. In particular, variables of CL are mapped to variables of FLD. Anyway, I think I might have an explanation (see below). > > Second, I said that FLD is more general than Common Logic "in many respects." > > That claim holds true. In a well-defined sense, it is also strictly more > > general, since Common logic is just a first-order logic, while FLD can define > > non-1st-order dialects as well. > > Not sure what the claim is here. If you simply lift the restriction on > disjointness then your statement is strictly true (or at least, I have no reason > to suspect otherwise). If you don't, it isn't. > > >>> Besides, we have already agreed early on that variables are prefixed with a ?, > >>> and this is how one identifies them. > >> We agreed on that for our existing dialects. I never agreed to that for all > >> logic languages. I personally don't see why it is needed, unless you allow no > >> quantifiers, in which case you do. Again, seems like its a choice in language > >> design, not something to require of all. > > > > Not requiring variables to be disjoint from constants is an unnecessary > > complication that brings NO benefits whatsoever. I can't even imagine what a > > suitable XML framework would look like in that case. > > Why do you need to care what dialect designers who choose to do this do? The > XML syntax makes it totally obvious and unambiguous. This is definitely NOT an > issue with the XML syntax. So, you accept that in XML variables should be clearly marked? Then it is easy: The presentation syntax (minus the shortcuts) is an abstract syntax, so variables must be clearly marked as such. Instead of writing something like $Var(X) (in a run-of-the-mill abstract syntax) we write ?X, for brevity. The symbol X can be also a constant. We just consider ? to be part of the symbol, so ?X and X are different and variables end up to be disjoint from constants. It is like saying that the set {$Const(...)} is disjoint from the set {$Var(...)}. Did I get to the source of the confusion? Then maybe a note explaining this would suffice to clear this out? -- -- michael
Received on Tuesday, 19 May 2009 15:53:26 UTC