[SCL] Suggestion for SCL extension module

[Tanel Tammet]

Murray Altheim wrote:

> Tanel Tammet wrote:
>
>> .....
>> The goal of the module would be to allow SCL
>> to be extended with operators which are NOT
>> defined in SCL and have no meaning for SCL.
>>
>> Examples could be modal operators, negation-as-failure,
>> default rules, etc etc. All of these have their
>> own semantics and we cannot describe this
>> semantics in SCL spec.
>> ....
>> ==============
>> ostrich(dave).
>> forall X. extended_3(default-implies,bird(X),flies(X)).
>> =============
>> .....
>>    Then the example would be interpreted as
>>
>> ==============
>> ostrich(dave).
>> forall X. p1.
>> =============
>>
>>    where "p1" is this new prop variable
>>    (we could also have "forall X. Atom_1(p)."
>>    where "p" is a new constant, essentially
>>    a predicate).
>> .....
>
>
>  
>
> You don't mention a way to canonically identify new language components.
> The way this is done in RDF and OWL, XTM and I would hope SCL/CL/XCL is
> through some unique name in a fixed namespace. The safest road from what
> I can see is to use the same mechanism as everyone else has, the URI.

Sure the URI mechanism is a sensible convention.

However, I have problems understanding how the URI mechanism
would help us for this proposed module in SCL spec, except as
a trivial, non-normative  suggestion for implementors of
extensions.

For example, say that  the file

==============
ostrich(dave).
forall X. extended_3(default-implies,bird(X),flies(X)).
=============

is written as

==============
ostrich(dave).
forall X. 
extended_3(http://something.org/mylang/default-implies,bird(X),flies(X)).
=============

which is surely a sensible thing, but is IMHO outside the scope of  SCL.

For SCL both "default-implies" and 
"http://something.org/mylang/default-implies"
are constants with no internal structure whatsover. We could think about 
taking
a convention saying that instead of

==============
ostrich(dave).
forall X. 
extended_3(http://something.org/mylang/default-implies,bird(X),flies(X)).
=============
one should rather write

==============
ostrich(dave).
forall X. 
extended_3(URI(http://something.org/mylang/default-implies),bird(X),flies(X)). 

=============
where "URI" is a "reserved" word in SCL, but I do not see how
that would be helpful or necessary in the SCL scope. Sure people
could write their constructions in the latter form, and we could _suggest_
that this is good practice,  but there is nothing in SCL semantics which
would make any difference.

What _could_ make a small difference:

a) say we use the special string module which defines something like
  not(equal(string(a) ,string(b)) unless "a" and "b" are syntactically
  equal.  Now, "a" and "b" are still ordinary constants for all other
  SCL purposes except the special string operators.

b) then we could, in principle, do the same for URI-s, but
   rather we could just treat them as strings.

But I see not intuition behind having a special URI datatype in SCL.
Strings should  be enough for the SCL level.

It is true, though, that some OUTER layer could determine that
a particular string is an URI, and then use this information.

However, such OUTER information can be conveyed nicely
with the SCL annot function. You could say, for example,

==============
ostrich(dave).
forall X. extended_3(annot(type(URI), 
http://something.org/mylang/default-implies),bird(X),flies(X)).
=============
where all the "extended_3" and "annot" info is simply discarded by SCL, but
not necessarily discarded by an external system having its own special
language and semantics.

> So, the domain of the URIs developed as part of the SCL effort plus any
> extensions or concrete syntaxes developed by us would use a fixed URI
> domain, and extensions or concrete syntaxes developed by others would
> use a domain they control. It would be prohibited for anyone to use our
> domain to develop language components. These URIs don't necessarily have
> to show up in the concrete syntax itself (and of course wouldn't fit or
> be appropriate in many or most cases), but should be identified in the
> prose.

I would definitely not like to build any kinds of special URI mechanisms 
into
SCL spec. For one thing, the meaning of these is bound to be
controversial and vague, for another, we will then get LCL (large
common logic) similar to famous fiascos like PL/1, instead
of SCL (simple common logic). Even the string module in
full SCL is on the verge of being perhaps too complex
(and URI-s should build on strings, brr).

We could have something XML-ish in the XML syntax
of SCL, but then it should be clearly noted as an extra
layer, specific for XML syntax, not shared with SCL
abstract syntax or semantics or other SCL syntaxes.
Which is a bit worrisome, but the good points could
overweigh the negative ones (unless we push this
additional layer too far). I have no predetermined
views on this, and would rather consider it case-by-case.

It will make sense, though, to give URI-s for
all SCL language operators.  This is a good idea but
unrelated to the previous discussion.

To summarise: I agree that giving informal hints to implementors to
use URI-s in cases like that would be good, but I see no effects of
this idea or mechanism on SCL syntax or semantics itself.

My question was rather:

a) Should we incorporate the "extended_n" component ino full SCL?
b) If we do that, is the syntax scheme I suggested OK or are there
   any alternatives?
c) If we do that, which of the semantics schemes proposed seems
   to fit best or are there proposals for alternative semantics schemes?

Regards,
         Tanel Tammet