Re: Issue: FUNCTION-TYPE

[Masinter.pa@Xerox.COM]

My idea with FUNCTION-TYPE is to bring out a proposal which includes the
automatic coercion of symbols to functions, puts forward the removal of
the coercion in the discussion section (as possibly a new proposal) and
for this to be a discussion item at X3J13. It will be hard for it to be
a discussion item if it doesn't go out in the mail. The discussion
section of the proposal should say something like "The cleanup committee
generally supports this proposal, as far as it goes. Some members of the
committee feel strongly that it does not go far enough. We believe this
is an issue which deserves wider discussion in the community, since it
affects the position of X3J13 and Common Lisp with respect to the EuLisp
community."

Is that OK?

I'm trying hard to keep the administration of this uncolored by my own
opinion on the issues. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here's my opinion on the issue:


I promised a message on the issue of compatibility and our negotiating
position with EuLisp and ISO. I am finding it very difficult to compose.

The X3J13 statement clearly includes as one of the options we are able
to take is to propose a layered implementation strategy, i.e., that
there are simpler subsets of Common Lisp, full Common Lisp, and
supersets of full Common Lisp.

I believe that our current goal is to properly remove the ambiguities in
full Common Lisp and, where warrented, consider minor enhancements.

When dealing with subsets and supersets, I think that we also have
additional goals, that the layers properly nest (programs in a subset
will run in a superset), that it be possible (either by static analysis
or runtime) to tell whether a program in a superset would run in a
subset, etc.

I believe the proper position with regard to EuLisp and ISO's desire for
a simpler language as a standard is for it to be a subset. 

In the case of the FUNCTION-TYPE issue, it is critical that the FUNCTION
type be well specified in full Common Lisp, if it is a first-class type
in any subset. Otherwise, programs which depended on a clean dynamicly
accurate FUNCTIONP would not run in (arbitrary) full Common Lisp
implementations.

However, there is no need to remove the automatic coercion of symbols
and LAMBDA expressions in FUNCALL, APPLY and friends. It is certainly
possible to have a subset which does not include coercions which the
full language provides.

With regard to simplicity and coercions, the automatic coercion of
symbols and lambda expressions to their designated functions is not a
lot more complex than the coercion of (symbols?) and strings to
pathnames, or possibly even integers to complex floats.