hello,
i am just tryin to learn lisp from robert wilensky's common lispcraft.
But i am all stuck at the eval function use ..can somebody help me out
what does exactly eval is used for specially can you give me some
examples of complex code where it is being use.. coz its like i can get
the simpler examples but not gettin it utility for complex thinkgs
where it can be used..
Thanks
newbie ha scritto:
> hello,
> i am just tryin to learn lisp from robert wilensky's common lispcraft.
> But i am all stuck at the eval function use ..can somebody help me out
> what does exactly eval is used for specially can you give me some
> examples of complex code where it is being use.. coz its like i can get
> the simpler examples but not gettin it utility for complex thinkgs
> where it can be used..
> Thanks
Hi, I started learning lisp two years ago and I used eval
only once to write a lisp-like language similar to brl
(http://brl.sourceforge.net/brl_4.html). It's a very handy
tool for this kind of things.
matteo
In article <1140929811.970351.270010
@e56g2000cwe.googlegroups.com>, ·········@yahoo.co.in says...
> hello,
> i am just tryin to learn lisp from robert wilensky's common lispcraft.
> But i am all stuck at the eval function use ..can somebody help me out
> what does exactly eval is used for specially can you give me some
> examples of complex code where it is being use.. coz its like i can get
> the simpler examples but not gettin it utility for complex thinkgs
> where it can be used..
Just two examples from my practice - imagine that you write
screen saver, and you want to write program that calculate and
draw some cute 3d objects on the base of random ... formula.
Now, the problem - how to represent formulas? The simplest
answer is to represent them as expressions in the programming
language and evaluate as needed.
Or, second example - imagine that you want to write program
that process Boolean formulas. How will you represent that
formula? It is best to represent them as Lisp expression and in
that case, from time to time, it will be very handy to simply
EVALuate such formula.
I can describe few other problems from top of my mind. Of
course, all this can be done without EVAL, hey, everything can
be done in C. Just data structures and algorithms one develop
with time start to look like interpreter.
EVAL and whole code=data idea is somehow marginalized and
underdeveloped in Lisp. Scheme has better EVAL than Lisp.
However, representation of code as single linked list was
adequate in 1960's when memory was sparse, but it is kinda
obsolete today.
Majorinc wrote:
> In article <1140929811.970351.270010
> @e56g2000cwe.googlegroups.com>, ·········@yahoo.co.in says...
>
>
>>hello,
>>i am just tryin to learn lisp from robert wilensky's common lispcraft.
>>But i am all stuck at the eval function use ..can somebody help me out
>>what does exactly eval is used for specially can you give me some
>>examples of complex code where it is being use.. coz its like i can get
>>the simpler examples but not gettin it utility for complex thinkgs
>>where it can be used..
>
>
> Just two examples from my practice - imagine that you write
> screen saver, and you want to write program that calculate and
> draw some cute 3d objects on the base of random ... formula.
> Now, the problem - how to represent formulas? The simplest
> answer is to represent them as expressions in the programming
> language and evaluate as needed.
This would be much better done using functions, not eval. Represent
each formula as a function, and use funcall to evaluate.
> Or, second example - imagine that you want to write program
> that process Boolean formulas. How will you represent that
> formula? It is best to represent them as Lisp expression and in
> that case, from time to time, it will be very handy to simply
> EVALuate such formula.
Unless you are expecting to symbolicly manipulate the formulas, it would
again be better to represent each as a function.
> I can describe few other problems from top of my mind. Of
> course, all this can be done without EVAL, hey, everything can
> be done in C. Just data structures and algorithms one develop
> with time start to look like interpreter.
Not only can they both be done without eval, they can be done much
clearer, faster, and more naturally without eval. Eval is very very
rarely useful; it's mainly useful for recreating your own REPL. Other
cases are better off using macros or closures, both of which more
cleanly integrate with the rest of Lisp.
-- MJF
In article <······················@speakeasy.net>,
·····@hpalace.com says...
> Majorinc wrote:
> <graphics> would be much better done using functions, not eval. Represent
> each formula as a function, and use funcall to evaluate.
....
>
> Unless you are expecting to symbolicly manipulate the formulas, it would
> again be better to represent each as a function.
More usual than not, if one uses formulas as values, he want to
syntactically process them.
>
> Not only can they both be done without eval, they can be done much
> clearer, faster, and more naturally without eval.
> Eval is very very
> rarely useful; it's mainly useful for recreating your own REPL. Other
> cases are better off using macros or closures, both of which more
> cleanly integrate with the rest of Lisp.
Code=data is the single most important idea of Lisp and EVAL is
what make it possible. Lisp can exist without macros and
closures, but without EVAL it is not Lisp any more. Idea that
macros or closures more cleanly integrate with the rest
suggests me that you didn't understood the whole point.
Lisp is originally meant to be suitable for symbolic
processing, unlike Fortran which is suitable for numerical
processing only. If you process *formulas* as values, then eval
is very natural idea in many cases. If you deeply and
definitely despise idea of formulas as data, then eval is
really useless to you - but in that case, I think you use wrong
language.
On 9397 day of my life Majorinc wrote:
> Code=data is the single most important idea of Lisp and EVAL is
> what make it possible.
My point of view is just opposit. To resolve conflict, we should
define Lisp first :)
Perhaps, your statement (second part: "and EVAL is ...") is true for
original Lisp, but Lisp is evolving, and it is not true for Common
Lisp.
> Lisp can exist without macros and closures, but without EVAL it is
> not Lisp any more.
Perl has eval too (and many other `scripting' languages do). So
does perl have Lisp nature?
--
Ivan Boldyrev
Your bytes are bitten.
In article <··············@ibhome.cgitftp.uiggm.nsc.ru>,
···············@cgitftp.uiggm.nsc.ru says...
> On 9397 day of my life Majorinc wrote:
> > Code=data is the single most important idea of Lisp and EVAL is
> > what make it possible.
>
> My point of view is just opposit. To resolve conflict, we should
> define Lisp first :)
McCarthy seems to be on my side:
"It seems to me that LISP will probably be superseded for many
purposes by a language that does to LISP what LISP does to
machine language. Namely it will be a higher level language
than LISP that, like LISP and machine language, can refer to
its own programs."
>
> Perhaps, your statement (second part: "and EVAL is ...") is true for
> original Lisp, but Lisp is evolving, and it is not true for Common
> Lisp.
How do you think "code=data" can be possible without EVAL?
Macros fall short here, because code=data means that code can
be processed during runtime, just like data is usually
processed during runtime.
>
> > Lisp can exist without macros and closures, but without EVAL it is
> > not Lisp any more.
>
> Perl has eval too (and many other `scripting' languages do). So
> does perl have Lisp nature?
>
Phrase "Lisp nature" is to vague here.
I don't know why I bother replying, but here goes
Majorinc wrote:
>
> McCarthy seems to be on my side:
>
> "It seems to me that LISP will probably be superseded for many
> purposes by a language that does to LISP what LISP does to
> machine language. Namely it will be a higher level language
> than LISP that, like LISP and machine language, can refer to
> its own programs."
Hmm. Don't see "programmer use of EVAL" in his statement.
> How do you think "code=data" can be possible without EVAL?
> Macros fall short here, because code=data means that code can
> be processed during runtime, just like data is usually
> processed during runtime.
Do you think closures are not code? That closures are not data?
> > > Lisp can exist without macros and closures, but without EVAL it is
> > > not Lisp any more.
You completely miss the point. EVAL is the basic model of Lisp and can
be expressed in the same Lisp language. This is the powerful point. One
cannot as easily describe a C evaluator in C. That EVAL exists,
however, does not mean that actual explicit calls to EVAL are somehow
essential to Lisp programming. EVAL has a crucial role in the whole
process, but that role shouldn't be a speaking part. More like
"executive producer." If the executive producer weren't there, the play
could not go on. But he doesn't walk out to center stage to announce
his presence.
In article <1141144846.004236.193910
@e56g2000cwe.googlegroups.com>, ············@gmail.com says...
>
> You completely miss the point. EVAL is the basic model of Lisp and can
> be expressed in the same Lisp language. This is the powerful point. One
> cannot as easily describe a C evaluator in C. That EVAL exists,
> however, does not mean that actual explicit calls to EVAL are somehow
> essential to Lisp programming. EVAL has a crucial role in the whole
> process, but that role shouldn't be a speaking part. More like
> "executive producer." If the executive producer weren't there, the play
> could not go on. But he doesn't walk out to center stage to announce
> his presence.
Did you used assember? When Mccarthy says that assembler
programs can refer to assembler programs that exactly means
that assembler program can construct assembler code *during
runtime* and then execute it. The simplest example is that in
assembler, you can make a program that expands some loop to
whole available memory and then execute it. Instead of
executing
a <do someting>
jump a
assembler program can expand that _during runtime_ in the whole
available memory
a <do something>
<do something>
...
<do something>
jump a.
and execute it. On this way, speed of the program can be
significantly improved. Of course, this expansion has no sense
during compile time. In fact, it is not accidental McCarthy
does not speak about assembler, he speaks about machine code -
that means, no compilation at all.
Of course, it is possible to write many programs without any
use of eval, simply because many popular languages, like C,
Fortran, etc have not eval at all.
But, sometimes its clearly the most natural to use eval. When?
Each time you want to process formulas, not functions but
formulas - for example Boolean formulas. In that case, it is
the most natural to represent these formulas as Lisp
expressions, and then process them and evaluate as needed. All
during runtime, of course.
It is completely out of reach for macros. You mentioned
closures, but I do not really see how they can match eval for
this pretty basic purpose.
>
> But, sometimes its clearly the most natural to use eval. When?
> Each time you want to process formulas, not functions but
> formulas - for example Boolean formulas. In that case, it is
> the most natural to represent these formulas as Lisp
> expressions, and then process them and evaluate as needed. All
> during runtime, of course.
>
> It is completely out of reach for macros. You mentioned
> closures, but I do not really see how they can match eval for
> this pretty basic purpose.
>
Seems to me you might be better off with compile espesially if
you intend to use the formula in a loop.
What you seem to be missing is that eval needs to copy
the entire environment so it is quite expensive to run.
This is why it is generally avoided.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
In article <·················@mjolner.upc.no>,
··············@chello.no says...
> Seems to me you might be better off with compile espesially if
> you intend to use the formula in a loop.
> What you seem to be missing is that eval needs to copy
> the entire environment so it is quite expensive to run.
> This is why it is generally avoided.
Really, I must admit I missed that. But why that is the case?
Majorinc, Kazimir <·····@email.com> writes:
> How do you think "code=data" can be possible without EVAL?
Macros and closures.
> Macros fall short here, because code=data means that code can
> be processed during runtime
Macros can be compiled at runtime and the result used like any
previously compiled function or macro.
> , just like data is usually processed during runtime.
The overwhelming impression is that you do not understand what is
going on either with eval or macros.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
······@foo.com says...
> Majorinc, Kazimir <·····@email.com> writes:
>
> > How do you think "code=data" can be possible without EVAL?
>
> Macros and closures.
>
> > Macros fall short here, because code=data means that code can
> > be processed during runtime
>
> Macros can be compiled at runtime and the result used like any
> previously compiled function or macro.
Its not enough.
>
>
> > , just like data is usually processed during runtime.
>
> The overwhelming impression is that you do not understand what is
> going on either with eval or macros.
Its because you're plain stupido and you do not have a clue
what I'm talking about.
Majorinc, Kazimir <·····@email.com> writes:
> > The overwhelming impression is that you do not understand what is
> > going on either with eval or macros.
>
> Its because you're plain stupido and you do not have a clue
> what I'm talking about.
Given what you are "talking about" is complete idiocy, I take that as
a good thing. And, any comment like this coming from someone known to be
totally clueless (yet arrogant) fool obviously indicates the opposite.
Here's another thing (though I'm sure you are too much the internet
kook to even pay attention). EVAL really has nothing to do with
code=data in that it basically is a simple black box to a user. It
affords no manipulation whatsoever to its input. It simply
"evaluates" the form it is given. By means of eval you cannot in any
way interrogate, modify, or otherwise process the form _as data_.
Macros, on the other hand, provide a particularly convenient interface
to the language processor for exactly this sort of manipulation of
code _as data_. They are not necessary (you can use "normal"
functions to do all the work associated with a macro and you can call
them at any time to do this work), but they are especially convenient
for code as data processing due to where and when they interact with
the language processing model.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
······@foo.com says...
> Majorinc, Kazimir <·····@email.com> writes:
>
> > > The overwhelming impression is that you do not understand what is
> > > going on either with eval or macros.
> >
> > Its because you're plain stupido and you do not have a clue
> > what I'm talking about.
>
> Given what you are "talking about" is complete idiocy, I take that as
> a good thing. And, any comment like this coming from someone known to be
> totally clueless (yet arrogant) fool obviously indicates the opposite.
Stupido, go home and fuck with your mother, not with me!
You guys never learn.
Majorinc, Kazimir <·····@email.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> ······@foo.com says...
> > Majorinc, Kazimir <·····@email.com> writes:
> >
> > > > The overwhelming impression is that you do not understand what is
> > > > going on either with eval or macros.
> > >
> > > Its because you're plain stupido and you do not have a clue
> > > what I'm talking about.
> >
> > Given what you are "talking about" is complete idiocy, I take that as
> > a good thing. And, any comment like this coming from someone known to be
> > totally clueless (yet arrogant) fool obviously indicates the opposite.
>
> Stupido, go home and fuck with your mother, not with me!
That's about the typical comment one would expect from a complete
incompetent as you have shown yourself to be over and over again.
Oh, and I'm not fucking with you - I'm _LAUGHING_ at you.
> You guys never learn.
Rolls eyes. What an idiot.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
······@foo.com says...
> >
> > Stupido, go home and fuck with your mother, not with me!
>
> That's about the typical comment one would expect from a complete
> incompetent as you have shown yourself to be over and over again.
Well, it has litte to do with competence. It would be too off
topic to discuss what happens here, but basically, this is the
best possible answer on the communication known as "passive
aggression" ...
>
> Oh, and I'm not fucking with you - I'm _LAUGHING_ at you.
> Rolls eyes. What an idiot.
>
Hey, we already exhausted all levels of aggression possible on
Usenet, so this does not generate negative emotions any more.
Live long and prosper.
Majorinc wrote:
> How do you think "code=data" can be possible without EVAL?
> Macros fall short here, because code=data means that code can
> be processed during runtime, just like data is usually
> processed during runtime.
code=data doesn't imply code=data at runtime. code=data at runtime
doesn't imply the use of eval.
Macros take advantage of the code=data nature at compile-time (or
better, macroexpansion time).
Closures are another form of code=data, in the sense that closure can be
passed around as first-class values.
eval has issues that are solved by macros and closures. Your focus on
eval as the only valid expression of the code=data idea is far too narrow.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Closures are another form of code=data, in the sense that closure can be
> passed around as first-class values.
That's not what people usually mean by code=data, since even C allows
function pointers to be passed around as first-class values.
code=data generally implies some means to construct and manipulate the
code as data, not just use it as an opaque data object.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>Closures are another form of code=data, in the sense that closure can be
>>passed around as first-class values.
>
> That's not what people usually mean by code=data, since even C allows
> function pointers to be passed around as first-class values.
>
> code=data generally implies some means to construct and manipulate the
> code as data, not just use it as an opaque data object.
Among other things, I had something like (compile nil '(lambda (x) (+ x
x))) in mind, which has some of the problems of eval but not all of them.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Sun, 26 Feb 2006 03:06:51 +0100, Majorinc, Kazimir <·····@email.com>
tried to confuse everyone with this message:
>In article <1140929811.970351.270010
>@e56g2000cwe.googlegroups.com>, ·········@yahoo.co.in says...
>
>> hello,
>> i am just tryin to learn lisp from robert wilensky's common lispcraft.
>> But i am all stuck at the eval function use ..can somebody help me out
>> what does exactly eval is used for specially can you give me some
>> examples of complex code where it is being use.. coz its like i can get
>> the simpler examples but not gettin it utility for complex thinkgs
>> where it can be used..
>
>Just two examples from my practice - imagine that you write
>screen saver, and you want to write program that calculate and
>draw some cute 3d objects on the base of random ... formula.
>Now, the problem - how to represent formulas? The simplest
>answer is to represent them as expressions in the programming
>language and evaluate as needed.
>
>Or, second example - imagine that you want to write program
>that process Boolean formulas. How will you represent that
>formula? It is best to represent them as Lisp expression and in
>that case, from time to time, it will be very handy to simply
>EVALuate such formula.
It's much better to use FUNCALL or APPLY. In such examples EVAL is
totally uncalled for. In the 3D screensaver example it also creates a
security hole of gigantic proportions by allowing it to execute
arbitrary code.
--
|WAR HAS NEVER SOLVED ANYTHING|,----- Timofei Shatrov aka Grue---------.
|(except for ending slavery, ||mail: grue at mail.ru ================ |
| fascism and communism) ||============= http://grue3.tripod.com |
|...and Saddam's dictatorship |`----------------------------------[4*72]
In article <················@news.readfreenews.net>,
····@mail.ru says...
> It's much better to use FUNCALL or APPLY. In such examples EVAL is
> totally uncalled for.
Wrong.
> In the 3D screensaver example it also creates a
> security hole of gigantic proportions by allowing it to execute
> arbitrary code.
This has no sense.
newbie wrote:
> hello,
> i am just tryin to learn lisp from robert wilensky's common lispcraft.
> But i am all stuck at the eval function use ..can somebody help me out
> what does exactly eval is used for specially can you give me some
> examples of complex code where it is being use.. coz its like i can get
> the simpler examples but not gettin it utility for complex thinkgs
> where it can be used..
> Thanks
>
Forget eval.
Sorry, don't know Wilensky or how he got into it. eval is cool in that
one can use it to programmatically generate source and then convert it
to, say, a callable function. But I say "forget eval" because (a) that
requirement is such a special case and (b) you can code Lisp for years
without needing it. I have used eval once in ten years, and I have been
doing heavy-duty, metalevel stuff the whole time.
If you want to get into the programmable language thing, read Graham's
"On Lisp", available on the web somewhere. But that is still advanced
stuff you might not need until you have been lisping for a good, intense
month.
ken
In article <···················@news-wrt-01.rdc-nyc.rr.com>,
·············@nyc.rr.com says...
> If you want to get into the programmable language thing, read Graham's
> "On Lisp", available on the web somewhere.
>
There is a lot more power in "code = data" than in
"programmable programming language" idea.
"newbie" <·········@yahoo.co.in> writes:
> hello,
> i am just tryin to learn lisp from robert wilensky's common lispcraft.
> But i am all stuck at the eval function use ..can somebody help me out
> what does exactly eval is used for specially can you give me some
> examples of complex code where it is being use.. coz its like i can get
> the simpler examples but not gettin it utility for complex thinkgs
> where it can be used..
> Thanks
You might enjoy this example
http://lambda-the-ultimate.org/node/587?from=76&comments_per_page=1
but remember the old saying:
code that writes code that writes code
make a programmers head ...... explode
and that care!
I nearly had a real life use of eval a few weeks ago. It was
for a database thingy.
(defun select (list-of-columns predicate-form table)
It seemed natural to do
(progv column-names
row-from-table
(eval predicate-form))
Then I realised that eval would repeat the syntactic
analysis of the predicate form for every damn row in the
table, really slowing things down, so what I really needed
to do was align the list-of-columns with the column-names
and massage the predicate form into a lambda expression so
that I could compile it once and for all before applying it
to all the rows of the table.
Alan Crowe
Edinburgh
Scotland