Hi there!
I'd like to define new macro in cl package silently.
How I'll do that? For now I have:
(
#+sbcl
sb-ext:without-package-locks
#+allegro
excl::without-package-locks
#+lispworks
let
#+lispworks
((lw:*handle-warn-on-redefinition* :warn)
(*packages-for-warn-on-redefinition* nil))
#-(or allegro lispworks sbcl)
progn
;; reusing cl symbols to avoid interning to cl
(defmacro let1 (variable + &body progn)
"Shortcut for (let ((a b)) . c) or (destructuring-bind a b . c)"
(if (atom variable)
`(let ((,variable ,+)) ,@progn)
`(destructuring-bind ,variable ,+ ,@progn)))
(export 'let1)
)
What about other implementations?
On Feb 19, 7:50 pm, budden <···········@mail.ru> wrote:
> Hi there!
> I'd like to define new macro in cl package silently.
> How I'll do that? For now I have:
>
> (
> #+sbcl
> sb-ext:without-package-locks
> #+allegro
> excl::without-package-locks
> #+lispworks
> let
> #+lispworks
> ((lw:*handle-warn-on-redefinition* :warn)
> (*packages-for-warn-on-redefinition* nil))
>
> #-(or allegro lispworks sbcl)
> progn
In clisp there is (EXT:WITHOUT-PACKAGE-LOCK () ...) described in
http://www.clisp.org/impnotes.html#without-pack-lock
saludos
Karsten
Oops, the code is wrong :)
This looks to be better, but it still needs to be tested on all
implems.
(defmacro portably-without-package-locks (&body body)
`(#+sbcl sb-ext:without-package-locks
#+allegro excl::without-package-locks
#+lispworks let
#+lispworks
((lw:*handle-warn-on-redefinition* :warn)
(*packages-for-warn-on-redefinition* nil))
#+clisp ext:without-package-lock #+clisp ()
#-(or allegro lispworks sbcl clisp)
progn
,@body))
budden <···········@mail.ru> writes:
> Well, thanks, now it looks like
> More implementations please (especially ccl)?
(let ((ccl:*warn-if-redefine-kernel* nil))
...)
--
Thomas A. Russ, USC/Information Sciences Institute
>>>>> "budden" == budden <···········@mail.ru> writes:
budden> Well, thanks, now it looks like
budden> (defmacro portably-without-package-locks (&body body)
budden> `(#+sbcl sb-ext:without-package-locks
budden> #+allegro excl::without-package-locks
budden> #+lispworks let #+lispworks
budden> #+clisp ext:without-package-lock ()
budden> ((lw:*handle-warn-on-redefinition* :warn)
budden> (*packages-for-warn-on-redefinition* nil))
budden> #-(or allegro lispworks sbcl clisp)
budden> progn
budden> ,@body))
Don't know about others, but I never thought code sprinkled with
reader conditionals as being portable....
Ray
Raymond Toy <···········@stericsson.com> writes:
>>>>>> "budden" == budden <···········@mail.ru> writes:
>
> budden> Well, thanks, now it looks like
> budden> (defmacro portably-without-package-locks (&body body)
> budden> `(#+sbcl sb-ext:without-package-locks
> budden> #+allegro excl::without-package-locks
> budden> #+lispworks let #+lispworks
> budden> #+clisp ext:without-package-lock ()
> budden> ((lw:*handle-warn-on-redefinition* :warn)
> budden> (*packages-for-warn-on-redefinition* nil))
> budden> #-(or allegro lispworks sbcl clisp)
> budden> progn
> budden> ,@body))
>
> Don't know about others, but I never thought code sprinkled with
> reader conditionals as being portable....
Indeed. It's a portability layer, but is not in itself portable.
It is ported to some implementations.
--
__Pascal Bourguignon__
On 2009-02-20, budden <···········@mail.ru> wrote:
> Well, thanks, now it looks like
>
> (defmacro portably-without-package-locks (&body body)
> `(#+sbcl sb-ext:without-package-locks
> #+allegro excl::without-package-locks
What you are doing is inherently nonportable. Mucking around within the CL
package is undefined behavior. This is not a ``user serviceable'' part of
Common Lisp.
Package locking helps to diagnose that something nonportable is happening in a
program. Without package locking, programs could accidentally redefine
functions and macros in the the COMMON-LISP package.
I.e. you're asking for a /portable/ way to defeat a commonly implemented
mechanim whose purpose is to guard against something /nonportable/ from
happening, which is irrational nonsense.
Even if you defeat the lock, the action that you intend to take, which is
prevented by that lock, still leaves your code nonportable. It's not the lock
guard which makes it nonportable!
For instance if you break the lock on the CL package and rewrite the function
LIST, you don't know whether a macro like LOOP will use your LIST, or continue
to using the original LIST.
Stop being a twit already.
On Feb 19, 7:50 pm, budden <···········@mail.ru> wrote:
> Hi there!
> I'd like to define new macro in cl package silently.
Just out of curiosity, why don't you use some variation of:
(defpackage #:budden-lisp
(:nicknames #:bl)
(:use #:cl)
(:export . #.(let ((cl-symbols '()))
(do-external-symbols (sym :cl cl-symbols)
(push (make-symbol (symbol-name sym))
cl-symbols))))
(:export #:let1))
On Feb 20, 2:05 pm, budden <···········@mail.ru> wrote:
> > (defpackage #:budden-lisp
>
> Because I'm redefining find-symbol and intern to alter default package
> system behaviour.
> Let1 was for example only.
(defpackage #:budden-lisp
(:nicknames #:bl)
(:use #:cl)
(:export . #.(let ((cl-symbols '()))
(do-external-symbols (sym :cl cl-symbols)
(push (make-symbol (symbol-name sym))
cl-symbols))))
(:shadow #:find-symbol #:intern))
(in-package #:budden-lisp)
(defun find-symbol (&rest args)
(princ "Mine!" *trace-output*)
(apply #'cl:find-symbol args))
(defun intern (&rest args)
(princ "Mine!" *trace-output*)
(apply #'cl:intern args))
As you noted, LET1 was for example only.
Of course, your versions are not used by functions and macros in the
CL package (and neither should they), but then again just overriding
the package lock does not guarantee that either. An implementation is
free to do a lot of things behind your back.
For a reliable solution you probably have to identify the functions
using your new features and extend/replace them. If it's the reader,
Pascal Bourguignon has done the exercise, and IIRC, there's also one
in SACLA.
From: Pascal J. Bourguignon
Subject: Re: portable disabling of cl package lock
Date:
Message-ID: <87bpsxgrdg.fsf@galatea.local>
budden <···········@mail.ru> writes:
>> (defpackage #:budden-lisp
> Because I'm redefining find-symbol and intern to alter default package
> system behaviour.
> Let1 was for example only.
You don't need to override CL to do that.
Have a look at: http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
Check the ibcl:defpackage macro.
Notice that overriding operators in the package CL doesn't make the
other operators in this package use the overriden operators: an
implementation is free to open-code any of its functions (and of
course its macros will have been expanded long ago). Therefore you
will have to provide new functions anyways, therefore there's no point
in putting them in CL.
--
__Pascal Bourguignon__
> Notice that overriding operators in the package CL doesn't make the
>other operators in this package use the overriden operators: an
>implementation is free to open-code any of its functions (and of
>course its macros will have been expanded long ago).
Yes, but sometimes it does use overriden operators (at least,
lispworks does so for
intern and find-symbol).
Overall idea of what I want is here http://groups.google.com/group/comp.lang.lisp/msg/4c73d159bfcd7f16
,
code is here http://paste.lisp.org/display/75852 .
Thanks for references to alternative readers, for now I think the best
one comes from ccl. I can hook it up
and use it instead standard reader portably, but it needs to be
abstracted from ccl kernel functions,
they are to be replaced with common lisp functions. I'm too lazy to do
that.
From: Pascal J. Bourguignon
Subject: Re: portable disabling of cl package lock
Date:
Message-ID: <874oypgncn.fsf@galatea.local>
budden <···········@mail.ru> writes:
>> Notice that overriding operators in the package CL doesn't make the
>>other operators in this package use the overriden operators: an
>>implementation is free to open-code any of its functions (and of
>>course its macros will have been expanded long ago).
> Yes, but sometimes it does use overriden operators (at least,
> lispworks does so for
> intern and find-symbol).
So you write programs that work sometimes...
--
__Pascal Bourguignon__
budden <···········@mail.ru> wrote:
+---------------
| I'd like to define new macro in cl package silently.
| How I'll do that? For now I have:
...
| #+sbcl sb-ext:without-package-locks
...
| What about other implementations?
+---------------
CMUCL:
#+cmu ext:without-package-locks
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607