Re: Bridging the colon gap

[MOON@MIT-MC]

CC: JONL at MIT-MC
Well, the issue here is the ability to run Maclisp code with
no modification.  Such code would of course always run in the
USER package, which is supposed to be the package in which you
can run without any knowledge that there are such things as packages.
I think the only reason the keyword and user packages were made
the same was so that code without colons (presumably code from
Maclisp) would work in the USER package.  I think RMS's suggestion
that the keyword package should be superior to the user package
rather than identical to it is the right thing; unfortunately
implementing it will require recompiling everything.

Now, Maclisp code that runs in packages other than the USER package,
such as Macsyma for instance, naturally needs some conditionalization.
It doesn't seem to me to be that big a problem to have to conditionalize
the very few functions that exist in both Maclisp and Lisp machine Lisp
and take keyword arguments; OPEN and TRACE are the only ones that immediately
come to mind.  Even SFAs are not compatible with Lisp-machine streams.
And when you come to user functions that want to take keyword arguments
(as opposed to functions already wired into Lisp), the colon should simply
be regarded as part of the spelling of the symbol.  In Maclisp it really
will be part of the print name, but in the Lisp machine it will put it
in the keyword package.

The ONLY difference between the Lisp machine colon prefix and a simple
naming CONVENTION based on colons in print-names, is that in the Lisp
machine if you are inside a package you may leave out the prefix, for
brevity.  But no one is ever supposed to be inside the keyword package,
that is, you are never supposed to leave off the colon prefix, which is
only 1 character anyway, so that does not apply in this case.

It would certainly be a win if the Maclisp reader were improved so that
you could write a Lisp machine compatible colon macro for Maclisp,
which did whatever you like with the stuff to the left of the colon.
But that's a refinement, and would make no difference to the particular
case of keywords, except for OPEN.

TRACE, being a user interface rather than a program interface, should
regard its keywords as strings rather than symbols, and accept them
in any package, and with spelling correction, for that matter.  Actually,
the S-expression interface to trace is the wrong thing anyway, as we
have a display-oriented interface to trace which eliminates the need
to remember and type all these stupid keywords.

I don't understand what use #: would be.  It seems like there are very
few cases were you could use it by itself, and if you have to conditionalize
something else anyway, you might as well conditionalize any sumbols you
have with colons in them as well.

Note- at present in the Lisp machine system the whole issue has been
circumvented by globalizing the keyword options to OPEN (as well as a
large number of others for reasons having to do with the cold-load
which are no longer true), so that you get the same symbols no matter
what package you are in and whether or not you write the colon.

So what's all the fuss about, anyway?