From: Sam S. <sd...@gn...> - 2004-06-22 19:56:20
|
Bruno, what is the policy for SETF symbols? until recently, the norm has been (defsetf foo sys::%set-foo) you are now using (defsetf foo |SYS::(SETF FOO)|) 1. for the sake of consistency, could you _please_ convert all symbols to a single style? 2. if you do decide to use the new style, could you _please_ make sure that it complies with the return value of places.lisp:setf-symbol (amend either the style or the function, I don't care which). thank you very much. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> A poet who reads his verse in public may have other nasty habits. |
From: Bruno H. <br...@cl...> - 2004-06-22 20:20:50
|
Sam wrote: > what is the policy for SETF symbols? > until recently, the norm has been > (defsetf foo sys::%set-foo) > you are now using > (defsetf foo |SYS::(SETF FOO)|) More precisely, I'm aliasing (SETF SYS::FOO) to SYS::|(SETF FOO)|. The reasons are 1) It allows using #'(SETF SYS::FOO), thus making a better symmetry between setter and getter. 2) In C code, the sys::%set-foo has the new-value passed as last argument, whereas in |SYS::(SETF FOO)| it is passed as first argument. In the latter case the STACK offsets are the same as in the getter, which can make things simpler. 3) In error messages, it prints nicely. > 1. for the sake of consistency, could you _please_ convert all symbols > to a single style? I can put it on a TODO list, since it's not urgent. > 2. if you do decide to use the new style, could you _please_ make sure > that it complies with the return value of places.lisp:setf-symbol No. The places.lisp:setf-symbol function is currently broken, because it returns interned symbols. I have the appended patch in my queue, and will apply it at some time. The only reason I have not applied it yet is that it has an interaction with MAKE-LOAD-FORM that I don't understand. So, setf-symbol has to construct uninterned symbols always, but obviously in constsym.d we can declare only interned symbols. Bruno 2004-05-15 Bruno Haible <br...@cl...> * places.lisp (setf-symbol): Don't intern the resulting symbol. Fixes bug introduced on 2001-08-20. *** clisp-20040409/src/places.lisp.bak 2004-05-03 02:11:32.000000000 +0200 --- clisp-20040409/src/places.lisp 2004-05-16 05:10:30.000000000 +0200 *************** *** 6,20 **** ;;;---------------------------------------------------------------------------- ;;; Funktionen zur Definition und zum Ausnutzen von places: ;;;---------------------------------------------------------------------------- ! ;; Return a symbol for SYSTEM::SETF-FUNCTION ! ;; the returned symbol will be interned iff the argument is. (defun setf-symbol (symbol) (let* ((pack (symbol-package symbol)) (name (string-concat "(SETF " (if pack (package-name pack) "#") ":" (symbol-name symbol) ")"))) ! (if pack ! (intern name pack) ! (make-symbol name)))) ;;;---------------------------------------------------------------------------- ;; Returns the symbol which is on the property list at SYSTEM::SETF-FUNCTION (defun get-setf-symbol (symbol) --- 6,19 ---- ;;;---------------------------------------------------------------------------- ;;; Funktionen zur Definition und zum Ausnutzen von places: ;;;---------------------------------------------------------------------------- ! ;; Return a symbol for SYSTEM::SETF-FUNCTION. (defun setf-symbol (symbol) (let* ((pack (symbol-package symbol)) (name (string-concat "(SETF " (if pack (package-name pack) "#") ":" (symbol-name symbol) ")"))) ! ;; This must be an uninterned symbol because we are not allowed to ! ;; clobber interned symbols in user packages. ! (make-symbol name))) ;;;---------------------------------------------------------------------------- ;; Returns the symbol which is on the property list at SYSTEM::SETF-FUNCTION (defun get-setf-symbol (symbol) |
From: Sam S. <sd...@gn...> - 2004-06-22 21:04:57
|
> * Bruno Haible <oe...@py...t> [2004-06-22 22:11:00 +0200]: > >> 2. if you do decide to use the new style, could you _please_ make sure >> that it complies with the return value of places.lisp:setf-symbol > > No. The places.lisp:setf-symbol function is currently broken, because > it returns interned symbols. I have the appended patch in my queue, > and will apply it at some time. The only reason I have not applied it > yet is that it has an interaction with MAKE-LOAD-FORM that I don't > understand. been through this. MAKE-LOAD-FORM has nothing to do with this. FAS files cannot be written unless the SETF symbols are interned. (FAS is written readably and uninterned symbols cannot be written readably.) > ! ;; This must be an uninterned symbol because we are not allowed to > ! ;; clobber interned symbols in user packages. why? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> God had a deadline, so He wrote it all in Lisp. |
From: Sam S. <sd...@gn...> - 2004-06-22 21:28:41
|
> * Bruno Haible <oe...@py...t> [2004-06-22 22:11:00 +0200]: > >> 1. for the sake of consistency, could you _please_ convert all symbols >> to a single style? > > I can put it on a TODO list, since it's not urgent. I guess we have a different ideas of urgency. keeping CVS head nicely consistent is urgent to me, so I will do it myself. (I prefer keeping stuff clean - like a generational GC does, while you, apparently, want to clean-up only for releases). you check in your patches piecemeal - on an apparent assumption that someone is running the CVS head daily (so that the problems would be easy to pinpoint). well, that someone is certainly not me - I cannot use CVS head because of the incessant contagion warnings. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> cogito cogito ergo cogito sum |
From: Bruno H. <br...@cl...> - 2004-06-22 22:07:57
|
Sam wrote: > been through this. > MAKE-LOAD-FORM has nothing to do with this. > FAS files cannot be written unless the SETF symbols are interned. > (FAS is written readably and uninterned symbols cannot be written > readably.) Hmm, I'm thinking about treating uninterned symbols as if through (load-time-value (sys::get-setf-symbol 'original-symbol)) > > ! ;; This must be an uninterned symbol because we are not allowed to > > ! ;; clobber interned symbols in user packages. > > why? This is valid code: (defun |(SETF FOO)| () (do-what-i-want)) (defun (setf foo) (new-value x) (should-never-be-called)) (|(SETF FOO)|) Bruno |
From: Sam S. <sd...@gn...> - 2004-06-22 22:43:51
|
> * Bruno Haible <oe...@py...t> [2004-06-22 23:58:14 +0200]: > > Sam wrote: >> been through this. >> MAKE-LOAD-FORM has nothing to do with this. >> FAS files cannot be written unless the SETF symbols are interned. >> (FAS is written readably and uninterned symbols cannot be written >> readably.) > > Hmm, I'm thinking about treating uninterned symbols as if through > (load-time-value (sys::get-setf-symbol 'original-symbol)) looks good. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Apathy Club meeting this Friday. If you want to come, you're not invited. |
From: Bruno H. <br...@cl...> - 2004-06-22 22:10:39
|
Sam wrote: > so I will do it myself. Thanks, I appreciate this! You could also define a macro (def-setf-alias getter-symbol setter-symbol) that hides the detail about the property-list. > you check in your patches piecemeal - on an apparent assumption that > someone is running the CVS head daily (so that the problems would be > easy to pinpoint). > well, that someone is certainly not me - I cannot use CVS head because > of the incessant contagion warnings. Come on, put (setq *WARN-ON-FLOATING-POINT-RATIONAL-CONTAGION* nil) into your .clisprc until I find time to deal with it! Bruno |
From: Sam S. <sd...@gn...> - 2004-06-22 22:51:36
|
> * Bruno Haible <oe...@py...t> [2004-06-23 00:00:56 +0200]: > >> you check in your patches piecemeal - on an apparent assumption that >> someone is running the CVS head daily (so that the problems would be >> easy to pinpoint). >> well, that someone is certainly not me - I cannot use CVS head because >> of the incessant contagion warnings. > > Come on, put (setq *WARN-ON-FLOATING-POINT-RATIONAL-CONTAGION* nil) > into your .clisprc until I find time to deal with it! (cosh #c(1d0 2d0)) barfs regardless. and I want *WARN-ON-FLOATING-POINT-CONTAGION* to make sure I don't mix precisions. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Takeoffs are optional. Landings are mandatory. |
From: Bruno H. <br...@cl...> - 2004-06-23 21:05:58
|
Sam wrote: > MAKE-LOAD-FORM has nothing to do with this. > FAS files cannot be written unless the SETF symbols are interned. I think you've overlooked the real point. Compile this file and look at the .fas file: (eval-when (compile load eval) (defun (setf foo) (value a b) (list a b value))) (defvar func #'(setf foo)) (defvar f2 #.(compile nil (lambda (value) (setf (foo 3 4) value)))) (funcall f2 7) The code for FUNC doesn't contain a |(SETF COMMON-LISP-USER:FOO)| symbol. It contains the #. form, produced by load-time-value. As it should be. But the code for F2 contains a reference to the (should-be uninterned) |(SETF COMMON-LISP-USER:FOO)| symbol. This is brought in by the #.(compile nil ...). The bug is the expectation that compiled functions are externalizable objects (see CLHS 3.2.4.1 and 3.2.4.2.2). The bug is that in loadform.lisp compiled functions are created and then attempted to be printed readably. Only compiled-closures produced by COMPILE-FILE should be printed to a .fas file. Bruno |
From: Sam S. <sd...@gn...> - 2004-06-23 22:31:00
|
> * Bruno Haible <oe...@py...t> [2004-06-23 22:56:01 +0200]: > > The bug is the expectation that compiled functions are externalizable > objects (see CLHS 3.2.4.1 and 3.2.4.2.2). I always assumed that in CLISP all functions were externalizable, and saw it as a great and crucial feature. is it possible to make them so? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> When we write programs that "learn", it turns out we do and they don't. |
From: Bruno H. <br...@cl...> - 2004-06-24 11:04:54
|
Sam wrote: > I always assumed that in CLISP all functions were externalizable, and > saw it as a great and crucial feature. > > is it possible to make them so? I don't think so. The two obstacles are 1) load-time-value - a compiled function in memory has those already resolved, and no way to reconstruct the original form inside load-time-value, 2) references to outer bindings such as in (let ((x 0)) (list #'(lambda () (declare (compile)) (incf x)) ; compiled #'(lambda () (decf x)))) ; interpreted The great feature of clisp is that it uses the normal object syntax in fas files - this makes support of circular and user-defined data structures trvial. Bruno |