In article <8eff72$cj...@nnrp1.deja.com>, <wnew...@my-deja.com> wrote:As I said above, it depends on where in the process you implement the
>Isn't printing :FOO instead of KEYWORD:FOO already a special case?
>As long as you do this special thing, it's arguably simpler
>to do it always instead of only doing it sometimes.
special case. The logic could be:
(unless (symbol-in-package sym *package*)
where the PACKAGE-PREFIX function implements the special casing of the
(cond ((eq (symbol-package sym) *keyword-package*)
>I wish the KEYWORD package were a little more special, actually.I don't think the specification prohibits defining keywords as functions,
>I've been trying to decide what the SBCL interface for
>profiling and tracing should look like. It's based on the CMU CL
>TRACE code, and the CMU CL TRACE interface is basically nice, but
>relies heavily on the assumption that a keyword is not a function
>name, which as far as I can tell is not something which ANSI
>guarantees. So do I compromise the expressive CMU CL interface
>just to support people who want to
> (defun :foo (x) (1+ x))
> (trace :foo)
>Almost certainly, since I like systems to conform to standards.
>But it seems irksome in this case..
but realistically it's not a smart thing to do. The point of the package
system is to prevent unrelated pieces of code from interfering with each
other, but if two programmers both decide to define :FOO they'll clobber
each other when both applications are loaded into the same image.
This is very similar to the reasoning behind all the restrictions on the
I'm not familiar with the CMUCL trace implementation, but I wonder why they
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.