[SCL] two comments

[pat hayes]

>Gentlemen:

Jay & Randell, sorry for the delay in replying. In brief: yes, K&M 
were on of the old inspirations, indeed; and thanks for the reminder 
and suggestion.  But we are not here trying to make the most general 
possible framework, but rather to find a compromise between extreme 
generality and what might called broad user acceptance, particularly 
for implementors. There are no guidelines for how best to do this 
other than intuition and accumulated feedback from potential users, 
which often tells one that apparently trivial matters (such as the 
ability to properly axiomatize small universes, or the use of 
Unicode) can often loom large.

Your final point about context-sensitivity is well taken, and I 
agree. We still however need a way to present the ideas that is not 
automatically tied to context-free modes, such as EBNF. Can you 
suggest a widely accepted and understandable formal notation, 
analogous to EBNF, for displaying non-context-free syntax?

Pat


>Re (PH):
>
>>  We could get over this by being having just a single category of
>>  'constant', and let the interpretations distinguish between the
>>  cases, which is what I had in mind when writing the previous message.
>>  This would be in line with the basic 'extendable lexicon' intuition.
>>  This however would be a step back to the CL wild-west syntax, which I
>>  guess we should try to avoid (?).  Or we could just accept it, and
>>  remark that unambiguous context-free parsing requires that the basic
>>  categories can be assigned unambiguously in a context-free way (duh),
>>  and hence *derive* a conventional FO syntax from this syntactic
>>  condition.
>
>Without directly addressing disambiguation and the parsing questions, but
>with respect to having a single category of 'constants' and to extensible
>lexicons -  a lexicon which includes (in some way) both logical operators
>and non-logical  constants (such as relations and functions):
>
>Might the following suggest a potentially useful, uniform (and possibly
>parametizable) notation for being explicit about defining and rendering
>syntactical features of both logical and non-logical constants (in both FOL
>and its extensions)? This is the notation for variable-binding operators
>(including the standard FOL quantifiers and Boolean operators) presented in
>Kalish and Montague, _Techniques_of_Formal_Reasoning, (1st Ed. Kalish and
>Montague, Ch. VIII and IX  ; 2nd Ed., Kalish, Montague and Mar, Ch. X and
>XI). At least parts of this scheme might be adaptable to an SCL context.
>
>>From Chapter VIII (P. 271-2, 1st Ed.; Ch. X, P.438-9, 2nd Ed.):
>
>"... in symbolic languages... we distinguish two kinds of meaningful
>expressions, terms and formulas. Reverting to our informal characterization
>of these expressions, we may say that a term is an expression that becomes a
>name once its free variables are replaced by names, and a formula is an
>expression that becomes a sentence once its free variables are replaced by
>names...."
>
>"Variables are the simplest terms. Formulas, together with more complicated
>terms, are formed with the aid of constants, which fall into two classes,
>formula-makers and term-makers, according to the kind of expression that
>they generate. Each constant may be used in combination with a certain
>number of variables and previously generated terms and formulas to construct
>a new term or formula. To make this procedure precise, we shall associate
>with every constant a fixed degree, which will be a quadruple <I, M, N, P>
>of nonnegative integers, in which I is either 0 or 1. Here I is 0 or 1
>according as the constant in question is a term-maker or a formula-maker,
>and M, N, and P are respectively the number of variables, the number of
>terms, and the number of formulas that the constant demands. Our terms and
>formulas can then be exhaustively characterized as follows.
>
>...
>
>...We wish to include among our constants all the special symbols introduced
>in the previous chapters: '~', '=>', 'and',..., '=',... 'forall', 'exists',
>'the'. These symbols are called logical constants and are all formula-makers
>except for 'the' [which is a term-maker]. ... Constants other than [these]
>are called non-logical."
>
>
>K&M(&M) then proceed to rigorously develop this informal notation, in the
>context of (possible) definitional extensions of FOL theories, illustrating
>this development with various constants (logical and non-logical) for (and
>theories of):
>
>'the'
>identity
>set membership
>convergence of sequences, and limits (in calculus)
>roots (in algebra)
>
>and so forth. This style could also be adapted to record (for translation
>purposes) syntactical features of modal operators, etc. I don't know if
>SCLers are interested in the broader question of treating both logical and
>non-logical constants in this way, but, e.g., see also, for example:
>
><http://suo.ieee.org/email/msg06577.html>
>
>wherein CM discusses variable-binding operators (like 'kappa') as such.
>
>Returning to parsing issues: K&M adopt a parenthesis-free prefix notation
>for their offical purposes, but an  associated CFG wouldn't address the kind
>of ambiguity Pat is discussing, since K&M require the traditional
>non-overlap between predicates and function symbols, including individuals,
>Informally, of course, they use an parenthesized infix style which needs all
>sorts of further (contextual) disambiguation.
>
>But as we discussed, if the concrete syntax is infix there are still
>opportunities for predicate / function ambiguity. Only when one requires
>pre-declaration of predicates and functions (and plays interesting games
>with lexer to parser tie-ins -- games very familiar to those who've written
>parsers for C and C++) can those ambiguities be sidestepped.
>
>The real point is that expunging all context sensitivities, no matter how
>manageable they are in practice, is overkill and tends to produce languages
>that humans find tedious to write and read. Since recognizer technology has
>advanced beyond its early state, admitting some constructs that are not
>strictly context-free is actually desirable. Parsers remain tractable, the
>tools allow one to construct them readily and the resulting concrete syntax
>is more aesthetically palatable to human producers and consumers of that
>syntax.

>
>Cheers,
>Jay and Randall
>
>_______________________________________________
>SCL mailing list
>SCL at philebus.tamu.edu
>http://philebus.tamu.edu/mailman/listinfo/scl


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