[SCL] REQUEST FOR FEDBACK: core syntax

[Tanel Tammet]

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.

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!

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. 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.

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: 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.
 
(BTW, unfortunately you cannot have easy appending of files in XML,
but there is nothing which prohibits us to keep it easy.)

> 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.

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.

Regards,
              Tanel