Hello, i'm relatively new to Lisp, but i got acquainted with two
dialects already. They are
1. Common Lisp (LispWorks, AllegroCL) and
2. NewLISP - a scripting language by Lutz Mueller.
And my question is: is there a dialect of Lisp, which offers the
possibility of runtime lamba lists manipulations, as it is in NewLISP:
(define (foo x) (+ x x)) => (lambda (x) (+ x x))
(last foo) => (+ x x)
But in addition to this, i want all the flexibility Common Lisp has
down to low-level cons cell manipulation etc. I really want a REAL
lisp, but with that feature.
Thank you:-)
On Fri, 03 Apr 2009 06:46:43 -0700, jirafkoshka wrote:
> Hello, i'm relatively new to Lisp, but i got acquainted with two
> dialects already. They are
> 1. Common Lisp (LispWorks, AllegroCL) and 2. NewLISP - a scripting
> language by Lutz Mueller.
>
> And my question is: is there a dialect of Lisp, which offers the
> possibility of runtime lamba lists manipulations, as it is in NewLISP:
>
> (define (foo x) (+ x x)) => (lambda (x) (+ x x))
>
> (last foo) => (+ x x)
>
> But in addition to this, i want all the flexibility Common Lisp has down
> to low-level cons cell manipulation etc. I really want a REAL lisp, but
> with that feature.
Why do you need this, and what do you want to achieve?
CL of course has eval, so you can always implement newLisp features or
even all of that language, if that's your idea of a good time. Or you
can define a macro that saves the lambda form whenever you define a
function (or a lambda form, etc), and another that lets you retrieve
it.
The question is why -- tell us what you would be using this for, and
you might get much better solutions.
Tamas
I'm very glad to hear that it is possible in Common Lisp. Thanks.))
Now about the question "why":
My idea was all about symbolic optimization of lambda expressions. You
may look at this, like a genetic-optimization algorithm, which target
is the most suitable lambda expression (function). It is pure
combinatorial task, but it requires the manipulation to be performed
directly in memory (so, Pascal J. Bourguignon's replica about work
with files does not satisfy me)).
So, the need is to have many possible variations of many lambda lists
(a big mess) at the same time, and to operate upon them like any
objects (copy, modify like list, cut, append). I mean that they should
have state, also.
Excuse me, Pascal, but i could not get the point of your code, i mean
this line:
>> C/USER[21]> (third (fourth *))
A was able to expand the function foo, yes, but i was not able to get
a reference to any part of it, i mean to modify it)
It seems, that the way is just to manipulate quoted lambda expressions
and eval them each time (i mean apply), right?
Thank you, once more:)))
On Apr 3, 12:27 pm, ···········@gmail.com wrote:
> I'm very glad to hear that it is possible in Common Lisp. Thanks.))
> Now about the question "why":
> My idea was all about symbolic optimization of lambda expressions. You
Lisp is all about symbolic computation. Any Lisp may do that with
little effort.
On 3 abr, 12:27, ···········@gmail.com wrote:
> I'm very glad to hear that it is possible in Common Lisp. Thanks.))
> Now about the question "why":
> My idea was all about symbolic optimization of lambda expressions. You
> may look at this, like a genetic-optimization algorithm, which target
> is the most suitable lambda expression (function). It is pure
> combinatorial task, but it requires the manipulation to be performed
> directly in memory (so, Pascal J. Bourguignon's replica about work
> with files does not satisfy me)).
>
> So, the need is to have many possible variations of many lambda lists
> (a big mess) at the same time, and to operate upon them like any
> objects (copy, modify like list, cut, append). I mean that they should
> have state, also.
>
> Excuse me, Pascal, but i could not get the point of your code, i mean
> this line:>> C/USER[21]> (third (fourth *))
fourth gets the fourth element of a list. * is the last value returned
(in Pascal's case, it is this list:
(LAMBDA (X) (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO (+ X X)))
The fourth element in this list, therefore, is the list
(BLOCK FOO (+ X X))
The third element of this list is
(+ X X)
>
> A was able to expand the function foo, yes, but i was not able to get
> a reference to any part of it, i mean to modify it)
I think what you didn't do is evaluating the code. So, for instance:
(let* ((code (function-lambda-expression #'foo))
(modified-code (modify-lambda-expression code))
(modified-function (eval modified-code)))
;; Now that you have a new function, if you want to change the
global definition of
;; the function foo, you need to say it explicitly. Either you do
this:
(setf (symbol-function 'foo) modified-function)
;; Or, if you want the function foo to be compiled, you can do this:
(compile 'foo modified-function))
If you don't do the last two lines, you can still use the modified-
function, but the function foo will still remain the same old
function.
>
> It seems, that the way is just to manipulate quoted lambda expressions
> and eval them each time (i mean apply), right?
>
> Thank you, once more:)))
On Fri, 03 Apr 2009 08:27:24 -0700, jirafkoshka wrote:
> I'm very glad to hear that it is possible in Common Lisp. Thanks.)) Now
> about the question "why":
> My idea was all about symbolic optimization of lambda expressions. You
> may look at this, like a genetic-optimization algorithm, which target is
> the most suitable lambda expression (function). It is pure combinatorial
> task, but it requires the manipulation to be performed directly in
> memory (so, Pascal J. Bourguignon's replica about work with files does
> not satisfy me)).
>
> So, the need is to have many possible variations of many lambda lists (a
> big mess) at the same time, and to operate upon them like any objects
> (copy, modify like list, cut, append). I mean that they should have
> state, also.
Ok, so just keep the code as a list and modify that with your genetic
algorithm, and use
(compile nil lambda-form)
to compile it, then you can evaluate the result using the criteria
chose. Or if you don't want to compile, use eval. Extracting the
lambda forms from functions is an unnecessary complication, for which
I see no reason.*
That said, I don't really see the point of what you are doing. I
don't know what you are "optimizing" for, but if this is speed or some
other resource constraint, a profiler and disassembler are what you
need. Anyhow, of course CL can do what you want, even though I don't
see why you would want to do it, guess I am narrow-minded :-)
Tamas
* Sidenote: it is interesting how newLisp fits idiotic ideas like a
glove. Maybe it was designed for that?
On 3 апр, 20:40, Tamas K Papp <······@gmail.com> wrote:
> On Fri, 03 Apr 2009 08:27:24 -0700, jirafkoshka wrote:
> > I'm very glad to hear that it is possible in Common Lisp. Thanks.)) Now
> > about the question "why":
> > My idea was all about symbolic optimization of lambda expressions. You
> > may look at this, like a genetic-optimization algorithm, which target is
> > the most suitable lambda expression (function). It is pure combinatorial
> > task, but it requires the manipulation to be performed directly in
> > memory (so, Pascal J. Bourguignon's replica about work with files does
> > not satisfy me)).
>
> > So, the need is to have many possible variations of many lambda lists (a
> > big mess) at the same time, and to operate upon them like any objects
> > (copy, modify like list, cut, append). I mean that they should have
> > state, also.
>
> Ok, so just keep the code as a list and modify that with your genetic
> algorithm, and use
>
> (compile nil lambda-form)
>
> to compile it, then you can evaluate the result using the criteria
> chose. Or if you don't want to compile, use eval. Extracting the
> lambda forms from functions is an unnecessary complication, for which
> I see no reason.*
>
> That said, I don't really see the point of what you are doing. I
> don't know what you are "optimizing" for, but if this is speed or some
> other resource constraint, a profiler and disassembler are what you
> need. Anyhow, of course CL can do what you want, even though I don't
> see why you would want to do it, guess I am narrow-minded :-)
>
> Tamas
>
> * Sidenote: it is interesting how newLisp fits idiotic ideas like a
> glove. Maybe it was designed for that?
Didn't want to anger you, really))
Yes, the idea is idiotic, but in the domains, where operator
combinations can give good result it may solve some problems.
About newLISP - no, i don't think that it was designed for that.
Idiotic idea was completely mine.
Anyway, you've helped me a lot)
···········@gmail.com writes:
> I'm very glad to hear that it is possible in Common Lisp. Thanks.))
> Now about the question "why":
> My idea was all about symbolic optimization of lambda expressions. You
> may look at this, like a genetic-optimization algorithm, which target
> is the most suitable lambda expression (function). It is pure
> combinatorial task, but it requires the manipulation to be performed
> directly in memory (so, Pascal J. Bourguignon's replica about work
> with files does not satisfy me)).
>
> So, the need is to have many possible variations of many lambda lists
> (a big mess) at the same time, and to operate upon them like any
> objects (copy, modify like list, cut, append). I mean that they should
> have state, also.
>
> Excuse me, Pascal, but i could not get the point of your code, i mean
> this line:
>>> C/USER[21]> (third (fourth *))
The point was to extract the source expression. As you may have
noticed, FUNCTION-LAMBDA-EXPRESSION may pre-process the expression, and
return something that is not identical to the source.
> A was able to expand the function foo, yes, but i was not able to get
> a reference to any part of it, i mean to modify it)
>
> It seems, that the way is just to manipulate quoted lambda expressions
> and eval them each time (i mean apply), right?
This is correct. It is best to consider the image as a black hole.
This allows for efficient or restricted implementations that will provide
less retrospective features.
You may use something like:
(let ((arguments '(x))
(expression '(* x x)))
(compile 'my-function (list 'lambda arguments expression)))
to create programmatically a function such as:
(defun my-function (x) (* x x))
It is not entirely identical (DEFUN may have implementation specific
side effects). If you want the full DEFUN semantics then:
(eval `(defun ,fname ,arguments ,expression))
The s-exp returned by FUNCTION-LAMBDA-EXPRESSION should probably be
considered read only, so if you want to apply mutations, you should
first COPY-TREE the result of FUNCTION-LAMBDA-EXPRESSION. But it is in
general easier to implement purely functional transformations.
--
__Pascal Bourguignon__
http://www.informatimago.com
···········@gmail.com writes:
> Hello, i'm relatively new to Lisp, but i got acquainted with two
> dialects already. They are
> 1. Common Lisp (LispWorks, AllegroCL) and
> 2. NewLISP - a scripting language by Lutz Mueller.
>
> And my question is: is there a dialect of Lisp, which offers the
> possibility of runtime lamba lists manipulations, as it is in NewLISP:
>
> (define (foo x) (+ x x)) => (lambda (x) (+ x x))
>
> (last foo) => (+ x x)
>
> But in addition to this, i want all the flexibility Common Lisp has
> down to low-level cons cell manipulation etc. I really want a REAL
> lisp, but with that feature.
You definitely want Common Lisp.
C/USER[19]> (defun foo (x) (+ x x))
FOO
C/USER[20]> (function-lambda-expression (function foo))
(LAMBDA (X) (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO (+ X X))) ;
#(NIL NIL NIL NIL ((DECLARATION ALSO-USE-PACKAGES OPTIMIZE DECLARATION))) ;
FOO
C/USER[21]> (third (fourth *))
(+ X X)
C/USER[22]>
However, choose your CL implementation wisely,
FUNCTION-LAMBDA-EXPRESSION is allowed to return NIL.
Otherwise, nothing prevents you to do the needed bookkeeping yourself.
Have a look at http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
Also, we tend to still work with files, as they are convenient
persistent objects, so in general you have the source forms available,
you don't need to fish them from the lisp image. Moreover, you can
easily get at them using macros:
(defmacro define-function (name arglist &body body)
(print `(body --> ,@body))
(print `(I can do whatever I want with ,@body !))
`(defun ,name ,arglist ,@body))
C/USER[25]> (define-function foo (x) (+ x x))
(BODY --> (+ X X))
(I CAN DO WHATEVER I WANT WITH (+ X X) !)
FOO
--
__Pascal Bourguignon__
On Fri, 03 Apr 2009 15:46:43 +0200, <···········@gmail.com> wrote:
> And my question is: is there a dialect of Lisp, which offers the
> possibility of runtime lamba lists manipulations, as it is in NewLISP:
I guess that Pico Lisp is the closest match. It is
very "small" but it satisfy what you described. Check it
http://www.software-lab.de/down.html
--
Blog: http://kazimirmajorinc.blogspot.com
WWW: http://www.instprog.com
···········@gmail.com wrote:
> Hello, i'm relatively new to Lisp, but i got acquainted with two
> dialects already. They are
> 1. Common Lisp (LispWorks, AllegroCL) and
> 2. NewLISP - a scripting language by Lutz Mueller.
>
> And my question is: is there a dialect of Lisp, which offers the
> possibility of runtime lamba lists manipulations, as it is in NewLISP:
>
> (define (foo x) (+ x x)) => (lambda (x) (+ x x))
>
> (last foo) => (+ x x)
>
> But in addition to this, i want all the flexibility Common Lisp has
> down to low-level cons cell manipulation etc. I really want a REAL
> lisp, but with that feature.
>
> Thank you:-)
(defclass my-function ()
((name :initarg :name :reader name)
(source :initarg :source :reader source))
(:metaclass funcallable-standard-class))
(defmacro my-defun (name (&rest lambda-list) &body body)
(let ((definition (gensym)))
`(progn
(defun ,name ,lambda-list ,@body)
(let ((,definition (make-instance
'my-function
:name ',name
:source '(lambda ,lambda-list ,@body))))
(set-funcallable-instance-function
,definition (fdefinition ',name))
(setf (symbol-function ',name) ,definition))
',name)))
C2CL-USER 4 > (my-defun foo (x) (* x x))
FOO
C2CL-USER 5 > (foo 5)
25
C2CL-USER 6 > (name #'foo)
FOO
C2CL-USER 7 > (source #'foo)
(LAMBDA (X) (* X X))
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/