Handle CLISP and LispWorks properly
phoe opened this issue · comments
There are workarounds for these two implementations:
lisp-namespace/src/namespace.lisp
Lines 11 to 14 in 28107ca
It does not seem that either of these implementations supply their own :AFTER method for DESCRIBE-OBJECT SYMBOL T; they only have package locking. In particular:
CLISP 2.49.93+
[1]> (ext:without-package-lock ("COMMON-LISP") (defmethod describe-object :after ((o symbol) stream) (print "hahaha" stream)))
#<STANDARD-METHOD :AFTER (#<BUILT-IN-CLASS SYMBOL> #<BUILT-IN-CLASS T>)>
[2]> (describe 'foo)
FOO is the symbol FOO, lies in #<PACKAGE COMMON-LISP-USER>, is accessible in 1 package COMMON-LISP-USER.
#<PACKAGE COMMON-LISP-USER> is the package named COMMON-LISP-USER. It has 2 nicknames CL-USER, USER.
It imports the external symbols of 2 packages COMMON-LISP, EXT and exports no symbols, but no package uses these
exports.
"hahaha"LispWorks 7.1.2 Personal
CL-USER 4 > (let ((lispworks:*handle-warn-on-redefinition* nil)) (defmethod describe-object :after ((o symbol) stream) (print "hahaha" stream)))
#<STANDARD-METHOD DESCRIBE-OBJECT (:AFTER) (SYMBOL T) 4020158D5B>
CL-USER 5 > (describe 'foo)
FOO is a SYMBOL
NAME "FOO"
VALUE #<unbound value>
FUNCTION #<unbound function>
PLIST NIL
PACKAGE #<The COMMON-LISP-USER package, 5/16 internal, 0/4 external>
"hahaha" It would be even better if we first checked if such a method already exists - then we can avoid overwriting it.
good suggestion.
My wish was, though, to make this library part of the standard.
I don't know how that's possible and I don't think it will ever happen actually.
The CL standard won't ever move, but we can try to write some good enough APIs and documentation and tests and examples to try and make it a de-facto standard. I'll try to make the latter happen over the next few days.
we can try to write some good enough APIs and documentation and tests and examples to try and make it a de-facto standard
hmmm.... I do not recommend it, unless you have tons of free time. There are other ways to spend your life on.
I am constantly dreaming of a lisp that is a successor of CL and has a fundamental improvement over it.
By "fundamental" I mean not like CL21 (e.g. ideas in CL21 are pretty much surface level / usability improvement) but the one which affects the type system and so on.
So if I ever seriously consider something about a new standard etc., it will be when I work on such a language, rather than on working on CL community directly.
I do not recommend it, unless you have tons of free time. There are other ways to spend your life on.
I think that a decent and working and documented CL interface is something that can be eventually ported to a CL successor of some sort, whenever it happens. CL is a good enough testbed for new language syntax.
I think that a decent and working and documented CL interface is something that can be eventually ported to a CL successor of some sort, whenever it happens.
agreed
CL is a good enough testbed for new language syntax.
This is also true (being able to write a pattern matcher within the language is one evidence).
One question I keep having recently, though, is ... Is CL also a good enough testbed for a new language semantics?
Syntax is relatively superficial --- a macro eventually compiles down to raw CL code, thus even a sophisticated macro would not alter the semantics of CL. To change the semantics of a language, we should really make it easy to dive into the compiler, and that is not easy in the current state of CL.
The best way to explore that is to grab a Common Lisp implementation and start tweaking it until it's no longer CL and has different semantics. Maybe CCL would work well for that, since it's much simpler compared e.g. to SBCL.
Indeed. I once looked into both CCL and SBCL code. I ran out of time, but I will be back, I hope.