[SCL] Re: Call for simplicity: Re: SCL 1.02.

[pat hayes]

>Hi,
>
>Chris Menzel wrote:
>
>>Tanel and Pat,
>>
>>The translation from general SCL to traditional FOL is a bit trickier
>>than I thought, given our approach that allows only some predicates to
>>be constants.  It requires, in general, translating from an SCL language
>>into a 2-sorted language, though one with general terms that can cut
>>across both sorts.  The details are straightforward, but it's taking me
>>rather longer to work out the details than I'd thought it would.
>>
>I am not surprised.
>
>My gut feeling is that the whole idea of allowing "only some 
>predicates to be constants"
>by introducing two types and special "id(x)" and "pred(x)" 
>predicates is an ugly
>hack which will:
>
>-  bring unexpected complications in almost everywhere, quite likely making
>    it unusable in practice
>  - will NOT be popular among readers, perceiving it as an unnecessarily
>     complex machinery ("let us rather stick to good old SFOL instead of
>     this mess")
>  - will buy us nothing (ie no positive aspects stemming from the
>    machinery).
>
>I'd strongly suggest to take the approach where we have only one
>type of constants. No special "predicate" and "non-predicate" constants.

That is certainly appealing.  HOwever, we need to face up to the 
Horrocks sentences when stating the idea that FOL is a legal SCL 
language.  The complication arises when we need to say what exactly 
"an SCL language" is and how it relates to the SCL abstract syntax 
and attached model theory. It has to be possible, I suggest, that 
GOFOL with a standard GOFOL MT is a legal SCL language. If we adopt 
the simpler MT then this is not achieved automatically by restricting 
the syntax to the GOFOL subcase, since the denotations of the 
relations are still in the universe of discourse in all models.  I 
see no obvious way past this which is not isomorphic in some way with 
the idea Chris has been developing.

>As I understood, this is the approach what both of you actually like,
>but were afraid to use in fear of accusations of  introducing "complex,
>fancy, impractical stuff".
>
>Listen: the two-kinds-of-constants approach is the complex,
>fancy and impractical thing, while the simple approach of
>having only one type of constants usable everywhere is
>much easier to understand and use.
>
>I am practically certain that we can present the simple approach
>in the SCL spec in a way that is comprehensible and does NOT
>look like a weird hard-to-understand hack.
>
>It is just a matter of the style or approach of presentation,
>rhetorics, if you will.

No, it is more than just that. One has to somehow get the model 
theory to come out right, without begging the question.

Put it very simply indeed. We have 2 SCL customers, called H and P, 
and the task is to define SCL syntax and model theory and a notion of 
a sublanguage so that both of them can be satisfied simultaneously.

H wants to just use a conventional FOL subset of SCL - we can easily 
define that syntactically as a sublanguage - and have it have the 
conventional FO model theory, and he wants to use equality.  So he 
wants
(x y)((x=y) & P(x)  & not Q(y))
to be consistent.

P wants to use full SCL, so that he can write things like
(r)(symmetric(r) iff (x y)(r(x,y) iff r(y,x) ) )
and have them means what they seem to mean.

What we need to do is to give a semantics for =, relational atoms and 
the universal quantifier which can satisfy both of these guys at the 
same time.  Its not a trivial task, since P needs things in his 
universe that will screw up H's intuitions if they are in his 
universe. How can we tell a single story which satisfies both 
requirements on what is in the universe? Chris' is the only one on 
the table at the moment, as far as I know.

Pat

>
>The main thing in achieving understandability and acceptance is
>to:
>- explain _why_ is this language practical (easy: RDF, Prolog,
>   KIF take this route in practice)
>- explain why it is not anything weird and new (simple: present
>   is as a simplification of SFOL, just like Pat did on the
>   way to Tampa)
>- Avoid any greek letters and one-letter names of concepts,
>   use long names, like good style of programming.
>- Write small and simple conversion algorithms and
>   semantics algorithms, avoiding any layers etc not
>   strictly necessary.
>
>But you know all of this :-)
>
>The draft chapters in the SCL draft spec I wrote take exactly
>the simple approach of  having only one type of constants.
>
>Read these chapters. Do they look like weird and incomprehensible,
>full of tricks? I do not think so, although they can be certainly
>further simplified and improved.
>
>As for the "decision" that we take the two-types-of.constants
>approach: there is no such decision. This is an idea you both
>had, but _nobody else_ in the SCL group understood or
>noticed. I am pretty sure that it is only Chris and Pat who
>have this idea, and in case you put it into the SCL spec,
>it will be a complete surprise (in a way) for other members
>of the SCL group (both in the narrow and the wide sense).
>
>I can understand that you are both interested in inventing
>something  non-obvious in the language, and two types
>of  constants certainly would be non-obvious. However,
>IMHO the SIMPLE approach is still a little bit (just a little
>bit) of novelty for the general public, and you do not need
>to invent anything fancier to get that novelty aspect.
>
>
>Regards,
>        Tanel


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