[SCL] REQUEST FOR FEDBACK: core syntax

[pat hayes]

>pat hayes wrote:
>
>>After thrashing around for a while, I think that the best choice 
>>for the 'core' syntax is a KIF-style syntax, but tweaked a little 
>>to make it easier to read.  Chief changes are these:
>>
>>1.  No explicit syntactic marking of variables: a variable is just 
>>a name which is bound by a quantifier. This makes the examples a 
>>lot less ugly to read for many people and gets rid of the need to 
>>handle free vars as a special case in the MT.
>>
>>2.  No explicit marking for forall and &: a conjunction is just a 
>>list of sentences and the unmarked quantifier case is the forall. 
>>So for example this KIF
>>
>>(forall (?x ?y)(implies (and (P ?x)(P ?y)) (P ?x ?y) ))
>>
>>would look like this:
>>
>>(x y)(implies ((P x)(P y)) (P x y) ))
>>
>I'd personally prefer prefix notation, not KIF (even though I am a 
>devoted Scheme hacker)
>since there are FAR more people accustomed to prefix notation when compared to
>people who are used to s-expressions. I'd guess at least one, 
>probably two magnitudes.

Yes, that was my original motivation for the infix syntax.  I keep 
going back and forth on this issue, there really is not a good single 
solution. The examples do definitely read more easily in a 
'conventional' notation; but the KIF-style syntax has clear 
advantages for machine use and ease of stating the translations and 
correspondence to the abstract syntax.

Perhaps the right thing to do is to introduce TWO notations at the 
same time early in the document. That would have the pedagogic 
advantage also of emphasizing the relative independence from surface 
syntax. Let us leave that until later and stick to the KIF-style 
syntax for now.

>
>This said, I could still live with the KIF notation as a core.
>
>The following issue is far more serious, though:
>
>in case you do NOT explicitly mark up forall and conjunction, 
>parsing will immediately
>become a nontrivial problem. We do not want to create this mess just for fun!

On reflection, I agree with you entirely and will abandon the 
unmarked simplification. I plan to retain the unmarked variables, 
however. The full KIF syntax is really very hard on the eyeballs.

>
>Consider your last example above rephrased in two ways:
>
>(dog y) (implies ((P dog)(P y)) (P dog y)))
>(and y) (implies ((P and)(P y))  (P and y)))
>
>How on earth do you recognise that (dog y) and (and y) are lists of variables?
>Since we have a slightly higher-order syntax, we might also have
>
>(dog y) (implies (dog y) ....)
>
>where dog was meant to be a variable!
>
>It is FAR simpler and better to have a fixed set of primitive names 
>like forall, and, implies, not
>which exactly determine the syntactic category of the list which they lead.
>
>Please let us avoid being "clever" with our core syntax: we will be 
>forever wed with
>the senseless confusion as a result.


OK, I am convinced.

>For example, the cleverness you suggested will soon
>lead us back to the KIF  question-marked-prefixed variables (why do 
>you think the ? prefix
>is there?).
>
>As for the conjunction being a list of sentences, it is a bit (but 
>just a bit) less horrible
>but still seriously unpleasant.
>
>Let me tell you what we really need :-), I wrote this in my draft once.
>
>This is important, not a joke!
>
>I am going to argue against interpreting a parenthesis-surrounded 
>list of formulas
>as a conjuction: (a) it makes parsing harder (b) it does not buy as 
>anything substantial,
>as I'll show next.
>
>When we consider SCL text as a file (as it typically happens) then 
>it is natural
>to consider such file as a sequence of formulas, implicitly conjuncted:
>--------
>(man John)
>(woman Mary)
>--------
>are typically read as a conjunction, and for good reason:
>such interpretation plays well with editing files, appending them,
>importing other files etc. All programming languages adapt
>similar semantics, etc.

Right. It was the ubiquity of sequence=conjunction convention which 
made me think of dropping the explicit conjunction marker in the 
kernel syntax.

>
>For SCL this means we'll have to take such a form into account and allow it.
>
>Now, observe there are typically NO parentheses around all the 
>top-level sentences
>in a file, and for good reason: if you require parentheses, then 
>appending of SCL files
>will not work any more as intended

Well, it was never my intention, but now you have pointed it out I 
take your point.  However, I do not quite see how this is an argument 
AGAINST the missing-AND convention. You seem to be providing 
excellent arguments in favor of it, if anything.  But OK, case closed.

>: if you append
>
>--------
>(
>(man John)
>(woman Mary)
>)
>--------
>to
>--------
>(
>(man Mark).
>(woman Astrud)
>)
>--------
>you get
>--------
>(
>(man John)
>(woman Mary)
>)
>(
>(man Mark).
>(woman Astrud)
>)
>--------
>
>where there are again no parentheses around the whole list of
>formulas inside.
>
>Hence we really need a concept of a sequence of formulas  (as you had the
>top level, and as I had in my draft, but with small differences: 
>please have a look)
>which is interpreted as conjunction.
>
>Now, this sequence should NOT be surrounded by parentheses, since this
>would remove the main idea (easy appending of files).
>
>Hence the idea of interpreting (a b c) as a conjunction does not really
>buy us anything, but will again create a confusion similar to that of
>the variable lists without a leading quantifier.
>
>Observe that in case you require obligatory headers, you lose appendability
>of files in a similar way.

I agree headers should be (and now are) optional.

>
>(BTW, unfortunately you cannot have easy appending of files in XML,
>but there is nothing which prohibits us to keep it easy.)

Hmmm, I had not thought about the appending of files issue, I 
confess. This requirement seems completely at odds with not just XML 
but the entire drift of how to design data for interchange, however. 
If you wish to deal with files considered as raw strings which can be 
concatenated at the character-string level, you seem to be playing a 
rather different game.

Still, there seems to be no good reason to require surrounding 
parentheses, so I guess they can go. Now done.

>
>>3. Use of parentheses and first-name-after-'(' as a universal 
>>grouping device, so that for example the header syntax will be
>>
>>(scl:ontology (scl:header <sentence>*) <sentence>+)
>>
>>rather than the ad-hoc double-colon thingie I invented.
>>
>>QUESTION: Any strong objections to this change?
>>
>Well, I gave a strong objection against dropping explicit syntax.

Indeed, and I am convinced.

>
>As for
>(scl:ontology (scl:header <sentence>*) <sentence>+)
>issue,  I'd need to understand the question. The form above seems 
>fine enough, except that
>I'd rather use a comment to indicate the header etc: I just do no 
>understand what we get
>from the  scl:ontology and scl:header.
>
>IMHO the information we'd convey there is
>completely out of the scope of SCL, and hence we should use a general comment
>syntax instead of having different kinds of comments (ordinary ones 
>and the ontology and header
>kinds of comments).
>
>You promised to write more about why we need the ontology and the 
>header special names.

The new draft has some of the header stuff in it, about datatypes. 
There will also be a section on using explicit argument lists and the 
consequences of being able to declare signatures explicitly.

Pat
-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes at ihmc.us       http://www.ihmc.us/users/phayes