Hi all:
In the REPL, after having played with a function and doing redefinitions,
done testing and tracing and such, how do I print the body (the newest
version) of my function in order to copy&paste it to my file buffer in
emacs?
Thx for any hints.
Regards,
Frank
--
Frank G�nninger, DG1SBG
Frank Goenninger DG1SBG wrote:
> Hi all:
>
> In the REPL, after having played with a function and doing redefinitions,
> done testing and tracing and such, how do I print the body (the newest
> version) of my function in order to copy&paste it to my file buffer in
> emacs?
Ideally, you should just be able to copy&paste it from the listener
history. (Your last defun should be somewhere in your listener.)
There is FUNCTION-LAMBDA-EXPRESSION that could be helpful, but it's not
guaranteed to work. See the HyperSpec for more details.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> There is FUNCTION-LAMBDA-EXPRESSION that could be helpful, but it's not
> guaranteed to work. See the HyperSpec for more details.
Here are some experiments. First, CLISP 2.33.
[1]> (defun roman (n) (format nil ··@R" n))
ROMAN
[2]> #'roman
#<CLOSURE ROMAN (N) (DECLARE (SYSTEM::IN-DEFUN ROMAN))
(BLOCK ROMAN (FORMAT NIL ··@R" N))>
[3]> (roman 4)
"IV"
[4]> (function-lambda-expression #'roman)
(LAMBDA (N) (DECLARE (SYSTEM::IN-DEFUN ROMAN))
(BLOCK ROMAN (FORMAT NIL ··@R" N))) ;
#(NIL NIL NIL NIL ((DECLARATION OPTIMIZE DECLARATION))) ;
ROMAN
Second, Allegro 6.2.
CL-USER(2): (defun roman (n) (format nil ··@R" n))
ROMAN
CL-USER(3): (roman 4)
"IV"
CL-USER(4): #'roman
#<Interpreted Function ROMAN>
CL-USER(7): (function-lambda-expression #'roman)
(LAMBDA (N) (BLOCK ROMAN (FORMAT NIL ··@R" N)))
NIL
ROMAN
Frank Goenninger DG1SBG <················@t-online.de> writes:
> Hi all:
>
> In the REPL, after having played with a function and doing redefinitions,
> done testing and tracing and such, how do I print the body (the newest
> version) of my function in order to copy&paste it to my file buffer in
> emacs?
Work in emacs in stead, at a minimum do an M-x shell in emacs and start
the lisp there. Even better, use slime or ilisp and send the function
definitions to the repl (which resides in another buffer) with shortcut
keys, and have lots of useful functionality for free, like changing the
package to the correct one on the fly.
Frank Goenninger DG1SBG <················@t-online.de> writes:
>
> Hi all:
>
> In the REPL, after having played with a function and doing redefinitions,
> done testing and tracing and such, how do I print the body (the newest
> version) of my function in order to copy&paste it to my file buffer in
> emacs?
The real answer is below. You can try using FUNCTION-LAMBDA-EXPRESSION
on what you created, but conforming implementations are allowed to not
store that information. You have to check your particular
implementation to see if the information is stored, if you can get it to
be stored by setting an option, or if you are out of luck.
> Thx for any hints.
Run the lisp job as a subprocess of Emacs. There are several tools for
doing this, such as SLIME and ILISP. Then the last form is already in
your Emacs buffer, ready for cutting and pasting.
>
> Regards,
> Frank
>
> --
>
> Frank G�nninger, DG1SBG
>
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Frank Goenninger DG1SBG <················@t-online.de> writes:
>
> >
> > Hi all:
> >
> > In the REPL, after having played with a function and doing redefinitions,
> > done testing and tracing and such, how do I print the body (the newest
> > version) of my function in order to copy&paste it to my file buffer in
> > emacs?
>
> The real answer is below. You can try using FUNCTION-LAMBDA-EXPRESSION
> on what you created, but conforming implementations are allowed to not
> store that information. You have to check your particular
> implementation to see if the information is stored, if you can get it to
> be stored by setting an option, or if you are out of luck.
Note that you can always do your own package COMMON-LISP-AS-IT-SHOULD-BE:
(defpackage "COMMON-LISP-AS-IT-SHOULD-BE"
(:use "COMMON-LISP")
(:shadow "DEFUN" "DEFVAR" #| DEFMACRO, DEFPARAMETER, etc |#)
(:export #| All the symbols exported by COMMON-LISP |#))
(cl:defvar *vdefinitions* (make-hash-table))
(cl:defvar *fdefinitions* (make-hash-table))
#| ... |#
(cl:defmacro defvar (name &optional value documentation)
`(progn
(setf (gethash ',name *vdefinitions*)
(list ,name ,value ,documentation))
(cl:defvar ,name ,value ,documentation)))
(cl:defmacro defun (name args &body body)
`(progn
(setf (gethash ',name *fdefinitions*)
(list ,name ,args ,body))
(cl:defun ,name ,args ,body)))
(defun dump-definitions ()
(maphash (lambda (name def) (print (cons 'defvar def)))
*vdefinitions*)
(maphash (lambda (name def) (print (cons 'defun def)))
*fdefinitions*)
#| ... |#)
Then instead of using COMMON-LISP:
(defpackage "COMMON-LISP-AS-IT-SHOULD-BE-USER"
(:use "COMMON-LISP-AS-IT-SHOUD-BE"))
(in-package "COMMON-LISP-AS-IT-SHOULD-BE-USER")
(defvar ...)
(defun ...)
and finally:
(dump-definitions)
COMMON-LISP-AS-IT-SHOULD-BE would be requisite for an image-based work.
> > Thx for any hints.
>
> Run the lisp job as a subprocess of Emacs. There are several tools for
> doing this, such as SLIME and ILISP. Then the last form is already in
> your Emacs buffer, ready for cutting and pasting.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
>> Frank Goenninger DG1SBG <················@t-online.de> writes:
>>
>> >
>> > Hi all:
>> >
>> > In the REPL, after having played with a function and doing redefinitions,
>> > done testing and tracing and such, how do I print the body (the newest
>> > version) of my function in order to copy&paste it to my file buffer in
>> > emacs?
>>
>> The real answer is below. You can try using FUNCTION-LAMBDA-EXPRESSION
>> on what you created, but conforming implementations are allowed to not
>> store that information. You have to check your particular
>> implementation to see if the information is stored, if you can get it to
>> be stored by setting an option, or if you are out of luck.
#'function-lamba-expression was a new one for me and almost does the job,
at least in ACL6.2.
>
> Note that you can always do your own package COMMON-LISP-AS-IT-SHOULD-BE:
>
> (defpackage "COMMON-LISP-AS-IT-SHOULD-BE"
> (:use "COMMON-LISP")
> (:shadow "DEFUN" "DEFVAR" #| DEFMACRO, DEFPARAMETER, etc |#)
> (:export #| All the symbols exported by COMMON-LISP |#))
>
> (cl:defvar *vdefinitions* (make-hash-table))
> (cl:defvar *fdefinitions* (make-hash-table))
> #| ... |#
>
> (cl:defmacro defvar (name &optional value documentation)
> `(progn
> (setf (gethash ',name *vdefinitions*)
> (list ,name ,value ,documentation))
> (cl:defvar ,name ,value ,documentation)))
>
> (cl:defmacro defun (name args &body body)
> `(progn
> (setf (gethash ',name *fdefinitions*)
> (list ,name ,args ,body))
> (cl:defun ,name ,args ,body)))
>
> (defun dump-definitions ()
> (maphash (lambda (name def) (print (cons 'defvar def)))
> *vdefinitions*)
> (maphash (lambda (name def) (print (cons 'defun def)))
> *fdefinitions*)
> #| ... |#)
>
> Then instead of using COMMON-LISP:
>
> (defpackage "COMMON-LISP-AS-IT-SHOULD-BE-USER"
> (:use "COMMON-LISP-AS-IT-SHOUD-BE"))
> (in-package "COMMON-LISP-AS-IT-SHOULD-BE-USER")
>
> (defvar ...)
> (defun ...)
>
> and finally:
> (dump-definitions)
>
>
> COMMON-LISP-AS-IT-SHOULD-BE would be requisite for an image-based work.
>
Now that is a very lispy way of dealing with it. Thx for the pointer and
the sample code!
>
>> > Thx for any hints.
>>
>> Run the lisp job as a subprocess of Emacs. There are several tools for
>> doing this, such as SLIME and ILISP. Then the last form is already in
>> your Emacs buffer, ready for cutting and pasting.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> Our enemies are innovative and resourceful, and so are we. They never
> stop thinking about new ways to harm our country and our people, and
> neither do we.
Pascal and all: Merci beaucoup, mes amis!
Frank
--
Frank G�nninger, DG1SBG
PRION Consulting Services AG
Nikolaus-Otto-Str. 25
D-70771 Leinfelden-Echterdingen
<http://www.prion-cs.de>