Hi all,
My program needs to use function eval, and need to count the number of
forms evaluated by eval. In cltl2, *evalhook* was mentioned, I thought
about using it, but soon found it's removed from the standard. I'm
wondering if there is any other way to do it. Thanks!
Hongmin
From: Pascal J. Bourguignon
Subject: Re: How to count number of forms evaluated?
Date:
Message-ID: <87tz5mkc7t.fsf@galatea.local>
·················@gmail.com writes:
> My program needs to use function eval, and need to count the number of
> forms evaluated by eval. In cltl2, *evalhook* was mentioned, I thought
> about using it, but soon found it's removed from the standard. I'm
> wondering if there is any other way to do it. Thanks!
The short answer is that it is impossible.
What do you really want?
If you want to count the number of times you call CL:EVAL, then don't
use it directly, use counted-cl:eval instead.
(defpackage "COUNTED-CL"
(:use "CL") (:shadow "EVAL")
(:export "EVAL" "*EVAL-COUNT*"))
(in-package "COUNTED-CL")
(defun eval (form) (incf *eval-count*) (cl:eval form))
Notice that CL:EVAL may compile the form, so it won't evaluate the
subforms, it will just generate code (or not) for them, and execute
this code. So you cannot count the subforms evaluated by CL:EVAL if
that was what you had in mind.
However, you could implement your own EVAL interpreter, and have a
counter incremented for each recursive call to your EVAL, that is to
each subform evaluated. If you implement your own EVAL interpreter
(or compiler) you could also provide *evalhook* or generate the code
to increment a form counter.
--
__Pascal Bourguignon__
Thanks!
I am trying to control the run time of eval as the argument passed to
eval are semi-randomly auto-generated code, which may contain things
like infinite loop. I'm afraid I still need count the subforms. Maybe
I'll just wrap each function that are used in the auto-generated
code...
Hongmin
On Mar 21, 1:38 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ·················@gmail.com writes:
> > My program needs to use function eval, and need to count the number of
> > forms evaluated by eval. In cltl2, *evalhook* was mentioned, I thought
> > about using it, but soon found it's removed from the standard. I'm
> > wondering if there is any other way to do it. Thanks!
>
> The short answer is that it is impossible.
>
> What do you really want?
>
> If you want to count the number of times you call CL:EVAL, then don't
> use it directly, use counted-cl:eval instead.
>
> (defpackage "COUNTED-CL"
> (:use "CL") (:shadow "EVAL")
> (:export "EVAL" "*EVAL-COUNT*"))
> (in-package "COUNTED-CL")
> (defun eval (form) (incf *eval-count*) (cl:eval form))
>
> Notice that CL:EVAL may compile the form, so it won't evaluate the
> subforms, it will just generate code (or not) for them, and execute
> this code. So you cannot count the subforms evaluated by CL:EVAL if
> that was what you had in mind.
>
> However, you could implement your own EVAL interpreter, and have a
> counter incremented for each recursive call to your EVAL, that is to
> each subform evaluated. If you implement your own EVAL interpreter
> (or compiler) you could also provide *evalhook* or generate the code
> to increment a form counter.
>
> --
> __Pascal Bourguignon__
From: Pascal J. Bourguignon
Subject: Re: How to count number of forms evaluated?
Date:
Message-ID: <87ljqyjnrd.fsf@galatea.local>
·················@gmail.com writes:
> I am trying to control the run time of eval as the argument passed to
> eval are semi-randomly auto-generated code, which may contain things
> like infinite loop. I'm afraid I still need count the subforms. Maybe
> I'll just wrap each function that are used in the auto-generated
> code...
I fail to see the relationship between run-time and number of subforms.
If you want to control the run time of a function call, why don't you
do so? Just write:
(with-timeout *max-run-time*
(eval random-form))
(apropos "WITH-TIMEOUT")
or use google groups for various definitions of with-timeout.
--
__Pascal Bourguignon__
By "run-time" or "number of subforms", I just want a way to measure
the complexity of the auto-generated code. I want to do a project on
Artificial Life in Lisp. The auto-generated code are the "living
organisms", they can mutate, evolve and compete. There has to be a
concept of "energy": running themselves cost energy, the more complex
the "living organism" is, the more energy is needed. By this concept,
with the same features, the simpler species would win in the "natural
selection" as they cost less energy and last longer and more chance to
reproduce. So, when I use eval to run them, a way to measure how much
energy they use it critical. Maybe I should just use a toy language to
express these "living organisms" Thanks!
Hongmin
On Mar 21, 10:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ·················@gmail.com writes:
> > I am trying to control the run time of eval as the argument passed to
> > eval are semi-randomly auto-generated code, which may contain things
> > like infinite loop. I'm afraid I still need count the subforms. Maybe
> > I'll just wrap each function that are used in the auto-generated
> > code...
>
> I fail to see the relationship between run-time and number of subforms.
>
> If you want to control the run time of a function call, why don't you
> do so? Just write:
>
> (with-timeout *max-run-time*
> (eval random-form))
>
> (apropos "WITH-TIMEOUT")
> or use google groups for various definitions of with-timeout.
>
> --
> __Pascal Bourguignon__
From: Pascal J. Bourguignon
Subject: Re: How to count number of forms evaluated?
Date:
Message-ID: <871vsqjbje.fsf@galatea.local>
·················@gmail.com writes:
> By "run-time" or "number of subforms", I just want a way to measure
> the complexity of the auto-generated code. I want to do a project on
> Artificial Life in Lisp. The auto-generated code are the "living
> organisms", they can mutate, evolve and compete. There has to be a
> concept of "energy": running themselves cost energy, the more complex
> the "living organism" is, the more energy is needed. By this concept,
> with the same features, the simpler species would win in the "natural
> selection" as they cost less energy and last longer and more chance to
> reproduce. So, when I use eval to run them, a way to measure how much
> energy they use it critical. Maybe I should just use a toy language to
> express these "living organisms" Thanks!
I'll refrain to answer, next time you'll invent yet another concept.
--
__Pascal Bourguignon__
·················@gmail.com wrote:
> By "run-time" or "number of subforms", I just want a way to measure
> the complexity of the auto-generated code. I want to do a project on
> Artificial Life in Lisp. The auto-generated code are the "living
> organisms", they can mutate, evolve and compete. There has to be a
> concept of "energy": running themselves cost energy, the more complex
> the "living organism" is, the more energy is needed. By this concept,
> with the same features, the simpler species would win in the "natural
> selection" as they cost less energy and last longer and more chance to
> reproduce. So, when I use eval to run them, a way to measure how much
> energy they use it critical. Maybe I should just use a toy language to
> express these "living organisms" Thanks!
If you're auto-generating the code, you can put the instrumentation in
the code you generate (each of your auto-generated subforms has a
prologue or epilog that increments a counter or whatever). Then you
could tweak the complexity measure by assigning different costs to
different kinds of subform. Or you could just do static analysis...
(If you're not worried about efficiency, this pretty much cries out for
an object-oriented design; if you are, it probably doesn't.)
paul
Thanks! Probably this the only way.
Hongmin
On Mar 22, 9:48 am, Paul Wallich <····@panix.com> wrote:
> ·················@gmail.com wrote:
> > By "run-time" or "number of subforms", I just want a way to measure
> > the complexity of the auto-generated code. I want to do a project on
> > Artificial Life in Lisp. The auto-generated code are the "living
> > organisms", they can mutate, evolve and compete. There has to be a
> > concept of "energy": running themselves cost energy, the more complex
> > the "living organism" is, the more energy is needed. By this concept,
> > with the same features, the simpler species would win in the "natural
> > selection" as they cost less energy and last longer and more chance to
> > reproduce. So, when I use eval to run them, a way to measure how much
> > energy they use it critical. Maybe I should just use a toy language to
> > express these "living organisms" Thanks!
>
> If you're auto-generating the code, you can put the instrumentation in
> the code you generate (each of your auto-generated subforms has a
> prologue or epilog that increments a counter or whatever). Then you
> could tweak the complexity measure by assigning different costs to
> different kinds of subform. Or you could just do static analysis...
>
> (If you're not worried about efficiency, this pretty much cries out for
> an object-oriented design; if you are, it probably doesn't.)
>
> paul