[SCL] Headers and bodies

[pat hayes]

>  > I think that the basic MT that we have worked out is right. It works,
>>  it has been stable now for quite a while, and we understand it fully.
>>  When we started, SCL was pretty damn simple: all names (except
>>  functions) were the same syntactic category and we didnt need anything
>>  like the complexity that we are now saddled with. Looking back, it
>>  seems to be that all of our problems have been to do, one way or
>>  another, with syntax.
>
>I agree.  I would prefer to have a very simple SCL core, which I could
>use as a base for defining CGIF (or Z, if I have the time).
>
>In fact, I would prefer to have only three operators in the core
>language:  the existential quantifier, conjunction, and negation.
>All other operators could be defined as syntactic combinations of
>those three.
>
>The current SCL 1.1 contains 2 quantifiers and 5 Boolean operators.
>But why include 5?  Why not 1? or 2? or 16?  One (either Nand or Nor)
>is sufficient, but since those are uncommon operators, I would prefer
>to have 2: And and Not.

More on the above.  It is possible to accommodate this kind of 
brevity in a particular concrete syntax by treating the defined forms 
as the concrete forms of the abstract language. For example, suppose 
your concrete syntax is KIFish but just has And, Not and forAll. Then 
you can say that your concrete syntax for (disjoin P Q) is an 
expression of the form (Not (And (Not [P]) (Not [Q]))), and your 
concrete syntax for (existential-quantification vars body) is (Not 
(forAll ([vars]) (Not [body]))) where [body] is your concrete form 
for the body, etc.. This enables a concrete syntax to be much more 
'minimal' than the abstract syntax, in effect by incorporating the 
definitions of the missing constructions into the way that the 
abstract SCL syntax is made concrete.

It would obviously be desireable that these forms should be 
transparent, in the sense that whether or not a parser 'notices' 
these defined forms, or instead parses all the way down to the basic 
(and/not/forall) concrete syntax should make no difference to the 
meaning. We could make this a conformance requirement, of course, in 
such a case.

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