Comments to [[SCL] new version improved slightly]

[Tanel Tammet]

Hi,

pat hayes wrote:

> The document at
>
> http://www.ihmc.us/users/phayes/SCL_december_2.HTML
>
> has some bugs fixed and a diagram to help see the relationship to the 
> presentation in your document.
>
> Comments/feedback would be very welcome whenever you (or anyone) has 
> them.

Some comments, suggestions and questions follow.

The general feeling I have about this: the basic stuff looks nice. IMHO some
smaller changes etc would be good (since it is an early draft, it 
obviously needs
work, and I be happy to help if I get some directions, more about that 
later).
More modularisation in presentation would be IMHO good when we move
closer to the final spec.

Some important issues are not covered in the spec yet and I am a bit 
worried about
how to approach these. I know how I'd approach them, but as we have seen,
this is not necessary the approach Pat or Chris would prefer.

 I' ll give the details in the following, starting with smaller
suggestions and then moving to more substantial issues.


1) Terminology.

I am not very happy with "skin", since it is normally
used in UI talk, not language talk. Everybody will understand it of course,
just feels a bit out of place (although certainly survivable).

The "ontology" vs theory or module has been talked about on the list.
I'd prefer theory, module being the second, and I do not particularly
like "ontology". Ontologies are theories of a specific kind, whereas
we are NOT assuming that only theories of a specific kind can be
imported. "Ontology" is not recognised as a neutral piece of terminology.

2) Syntax:

A) The examples are given mostly in "core syntax", with term/atom defined as
<term> ::= <term>*( * <term>* <seqvar>? *)* | <name> | <specialname>
and examples like "|married(Jack Jill)".

|I suggest to change this core syntax by adopting the convention of using
commas between terms in a sequence. Then we'll have the ordinary prefix 
syntax as
core syntax. The current core syntax is an uncommon compromise between
S-expression and prefix syntax.

Alternatively, if you do not like ordinary prefix syntax as core, let us 
rather use
s-expressions like KIF then.

B)  Related to this, I could not really understand the syntax definition
<term> ::= <term>*( * <term>* <seqvar>? *)* | <name> | <specialname>
since it DOES NOT specify any separators (comma, whitespace?).

C) Core syntax as presented avoids explicit "forall" and uses complex 
infix syntax a lot
(=, iff) making it hard to parse. I'd suggest avoiding any infix syntax 
in core
and using explicit quantifiers always: parsing will be much simpler. We can
have more user-friendly syntaxes anyway, there is IMHO no need to put
any nontrivial sugar into the core syntax.

3) Comments and headers and topsentences etc.

There is no talk about how comments and metainfo should be given.
Comments have to be put back into the core, preferrably into
the kernel.

Although I understand the principal need for headers, the current
talk about headers (unavoidably) stops too early. There is no indication 
about
what and how should be put there, and as such, one cannot use the
headers.

I'd rather see the headers and comments merged into one. Comments
should have no semantics for SCL (they should have semantics at the
level outside the scope of SCL). Since any headers can be written as 
comments,
I think we should not separate them. Comments are IMHO enough.

If/where they are not enough, then I am afraid that headers will
work neither.

As an example, consider http. The type of a body part of a http response
(gif, jpg, html, txt, doc etc) is NOT given as part of the body. It is
given as content-type in the http headers, which is on a _different_ level
than the http body itself. Similarly, any "headers" should IMHO be either
given as comments or they should not be at the SCL syntax level at all.

As another example, you just cannot declare
in XML text itself that now we are going to have something in arbitrary
NON-XML: this non-xml might contain less-than etc symbols, breaking the XML
syntax of the whole text.

I am also not sure we should use topsentence and allow imports at top 
level only.
IMHO we could allow import in any place, not just top level. This would
make the kernel more flexible while syntax is actually simplified.

4) Relations to TFOL

My pet issue has been the relation between SCL and traditional FOL.

The exact translation algorithms TFOL->SCL and SCL->TFOL have
to be a part of the SCL spec.

Now, despite the seemingly obvious nature of these algorithms (holds app 
stuff etc)
we have had remarkably different (and strong) views on how these translation
algorithms should look like.

Until these translation algorithms are there, I am not at all confident 
that I understand
this (or any other) SCL presentation as it is meant to be understood, 
and  I am not
confident that no major blunders have crept in.

IMHO these translation algorithms are a first priority.

5) Equality

The current presentation avoids equality issues. Like relations to TFOL,
these issues have been a major source of problems during the whole SCL 
process.

Again, until the equality issues have been covered in the spec, I am not 
at all
sure that we understand the presentation as it is meant to be understood 
or that
the presented semantics will work out without any crazy tricks.

The equality would be the second priority after the TFOL relations.

6) What to do next

Pat: now that you have this nice draft, what are you planning to improve
yourself and what could be left to other people?  Chris: how is your 
workplan?

I' d be happy to help writing, but we need to fix some plan for this. 
The precondition
of the plan, as noted before, is the common understanding of how this 
draft SCL
relates to TFOL and how is the equality handled.

Regards,
               Tanel










 









|
|



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031221/15c8a348/attachment.htm