[Openmcl-devel] Compiler warnings
tfb at tfeb.org
Wed Oct 21 10:08:19 UTC 2009
On 21 Oct 2009, at 09:52, Tobias C. Rittweiler wrote:
> As the consequences are undefined, implementations may conformingly
> grab for means outside the standard.
I think this is a really important point (I was half-way through a
message saying the same thing, but not so well).
It is clear that the standard for CL is not meant to be complete, in
the sense that a conforming implementation may have extensions to the
standard. For instance, a conforming implementation may define a
foreign function interface, or may have an object system which is not
CLOS (so long as it also has CLOS), or a MOP for CLOS. Or it may have
global lexicals, or all sorts of special top-level behaviours[*].
This is obvious, but there seems to be a trend for people to say
"because feature x is not in the standard, implementations may not
provide it". This is really only true where the standard *prohibits*
feature x, which may be because it directly conflicts with features
provided by the standard, because the standard just says "you may not
do x", because the feature would break conforming programs, or
possibly for other reasons.
I'm quite sure that the people who wrote the standard were not
intending it to have this stifling effect.
Anyway, I think this thread has used up too much space on this list so
I'll shut up now - it's unfortunate that there's no forum one can
really discuss these things on other than places like this or CLL,
which is generally too noisy.
[*] As an aside, I think it ought to be possible to *write* a top-
level which will create variables as top-level-lexicals (via the
symbol-macro trick as variously espoused) on the fly. I think the
hard part of this would be doing enough code walking to spot the
More information about the Openmcl-devel