On Fri, 23 Feb 2001 09:18:47 GMT, Kent M Pitman <······@world.std.com> wrote:
> Yes, you're missing the fact that since the formal syntax is in terms of
> text objects, it does not allow the compiler to compile conses/lists.
> If I do (list '+ '1 '2 '3) I get an object which has no semantics in the
> Scheme spec....
>
> Erik's point is quite legitimate here. Incidentally, I have complained
> about this at Scheme design meetings in the distant past, when we used to
> have them. This is not an oversight but quite a deliberate decision.
What were the justifications for that decision?
--seth
From: Kent M Pitman
Subject: Re: Lisp syntax : Lisp objects :: Scheme syntax : characters
Date:
Message-ID: <sfwpug8x2u8.fsf@world.std.com>
Seth Gordon <··········@lucent.com> writes:
>
> On Fri, 23 Feb 2001 09:18:47 GMT, Kent M Pitman <······@world.std.com> wrote:
> > Yes, you're missing the fact that since the formal syntax is in terms of
> > text objects, it does not allow the compiler to compile conses/lists.
> > If I do (list '+ '1 '2 '3) I get an object which has no semantics in the
> > Scheme spec....
> >
> > Erik's point is quite legitimate here. Incidentally, I have complained
> > about this at Scheme design meetings in the distant past, when we used to
> > have them. This is not an oversight but quite a deliberate decision.
>
> What were the justifications for that decision?
I don't really want to speak for the committee on this, because so many of
the others on the committee see the world so much differently from me.
Further, I don't know that anyone logs the rationales like we do in the
CL design. The rationale becomes, effectively, "we weren't convinced to
change it" or "we were convinced to change it" for any given issue.
I *think* the authors wanted to offer a grammar like is offered for other
languages, and using objects instead of text would have complicated the
explanations of things and would have made it hard for comparative language
study, but I might be misstating things. A lot of Scheme design has seemed
to me to be based on optimization for teaching rather than optimization for
usage, but again I rush to say that I'm hardly an unbiased observer.
Kent M Pitman <······@world.std.com> writes:
> Seth Gordon <··········@lucent.com> writes:
> > On Fri, 23 Feb 2001 09:18:47 GMT, Kent M Pitman wrote:
> > > Yes, you're missing the fact that since the formal syntax is in terms of
> > > text objects, it does not allow the compiler to compile conses/lists.
> > > If I do (list '+ '1 '2 '3) I get an object which has no semantics in the
> > > Scheme spec....
> > >
> > > Erik's point is quite legitimate here. Incidentally, I have complained
> > > about this at Scheme design meetings in the distant past, when we used to
> > > have them. This is not an oversight but quite a deliberate decision.
> >
> > What were the justifications for that decision?
One thing I can think of is the avoidance of ambiguities of the meaning of the
items being evaluated. Consider:
(let ((car (lambda (a) 'surprise)))
(eval '(car (1 2))) ; 1 or surprise?
(eval (list car 1 2))) ; 1 or surprise?
That is, does the meaning of what is being evaluated come from the symbols
print names being evaluated in the local scope, or from the the item's value?
By having scheme's formal syntax be in terms of text objects, things are
clearly always evaluated in the local scope, and the "problem" does not arise.
Not having a CL near me at the moment, what does CL do here?
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> Kent M Pitman <······@world.std.com> writes:
> > Seth Gordon <··········@lucent.com> writes:
> > > On Fri, 23 Feb 2001 09:18:47 GMT, Kent M Pitman wrote:
> > > > Yes, you're missing the fact that since the formal syntax is
> > > > in terms of text objects, it does not allow the compiler to
> > > > compile conses/lists. If I do (list '+ '1 '2 '3) I get an
> > > > object which has no semantics in the Scheme spec....
> > > >
> > > > Erik's point is quite legitimate here. Incidentally, I have
> > > > complained about this at Scheme design meetings in the distant
> > > > past, when we used to have them. This is not an oversight but
> > > > quite a deliberate decision.
> > >
> > > What were the justifications for that decision?
>
> One thing I can think of is the avoidance of ambiguities of the
> meaning of the items being evaluated. Consider:
>
> (let ((car (lambda (a) 'surprise)))
> (eval '(car (1 2))) ; 1 or surprise?
> (eval (list car 1 2))) ; 1 or surprise?
>
> That is, does the meaning of what is being evaluated come from the
> symbols print names being evaluated in the local scope, or from the
> the item's value?
>
> By having scheme's formal syntax be in terms of text objects, things
> are clearly always evaluated in the local scope, and the "problem"
> does not arise.
>
> Not having a CL near me at the moment, what does CL do here?
That code will not run. In this specific instance the ambiguity is as
much your fault as CL's. Do you mean to create a lexical variable or
function? If variable, should it be set to the result of the lambda,
or a quoted lambda list, or a function ? You can't set a symbol-value
to a function I believe. Do you mean to run "(car '(1 2))" or "(car 1
2)" , or maybe "((lambda (a) 'surprise) '(1 2))" ? You achieve the
latter with :
(let ((car '(lambda (a) 'surprise)))
(values ; sugar added: get both results
(eval (car '(1 2))) ; evaluates 1, which is 1
(eval (list car ''(1 2))))) ; evaluates the quoted lambda with arg
; '(1 2)
which returns:
1
SURPRISE
Please correct me if you meant something else.
If this is what you meant, please explain why this construct might
bite anyone (i.e. How is it ambiguous ? Why would you want to write
anything like the eval above ? If you wrote something like the above,
would that be in production code, or just as an experiment at the
prompt ?)
P.S: I realize that my writing comes off a bit snotty, but I *really*
want to know. I don't know much lisp (yet), I'm just working on
understanding this stuff.
--
H�kon Alstadheim, Montreal, Quebec, Canada
················@oslo.mail.telia.com (H�kon Alstadheim) writes:
> Please correct me if you meant something else.
>
> If this is what you meant, please explain why this construct might
> bite anyone (i.e. How is it ambiguous ? Why would you want to write
> anything like the eval above ? If you wrote something like the above,
> would that be in production code, or just as an experiment at the
> prompt ?)
>
> P.S: I realize that my writing comes off a bit snotty, but I *really*
> want to know. I don't know much lisp (yet), I'm just working on
> understanding this stuff.
Well, the eventual essence of my question was whether or not eval takes the
lexical environment into account.
The answer is no.
If the answer was yes, I was trying to construct a situation where evaluating
P::foo, for some symbol foo in P, would result in foo from *another* package.
I did not succeed, both due to my CL mistakes and due to the problem itself
(i.e. if the lexical context matters, 'foo should reasonably be looked up,
while foo should evaluate to whatever object is bound to it, no problem).
And no, I would not want to write such things in real code.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Kent M Pitman
Subject: Re: Lisp syntax : Lisp objects :: Scheme syntax : characters
Date:
Message-ID: <sfw66hxtf9s.fsf@world.std.com>
Ray Blaak <·····@infomatch.com> writes:
> One thing I can think of is the avoidance of ambiguities of the
> meaning of the items being evaluated. Consider:
Ambiguity arises not from weird test examples but from failure of a language
definition to specify what to do in those weird examples. In this particular
sense, CL is quite clear on what happens.
> (let ((car (lambda (a) 'surprise)))
> (eval '(car (1 2))) ; 1 or surprise?
> (eval (list car 1 2))) ; 1 or surprise?
Well, ignoring the problems with paren balancing and argument number here,
I assume the core of your question is whether the binding of CAR can
affect EVAL. In CL, it cannot, unless the binding is special, in which
case it always affects. But in any case the behavior is consistent.
In Scheme, they don't have EVAL, so they have a kind of consistent
behavior, too. Perhaps partly because they would need to take list args,
not text.
None of this has anything to do with text vs lists, really. These questions
would be in play regardless of where you defined the semantics.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Ray Blaak <·····@infomatch.com> writes:
>
>> (let ((car (lambda (a) 'surprise)))
>> (eval '(car (1 2))) ; 1 or surprise?
>> (eval (list car 1 2))) ; 1 or surprise?
>
>Well, ignoring the problems with paren balancing and argument number here,
>I assume the core of your question is whether the binding of CAR can
>affect EVAL. In CL, it cannot, unless the binding is special, in which
>case it always affects. But in any case the behavior is consistent.
>
>In Scheme, they don't have EVAL, so they have a kind of consistent
>behavior, too. Perhaps partly because they would need to take list args,
>not text.
In Scheme they do have EVAL, and have had it for several
years now. Vide R5RS (google for an online copy,
and scan the index for eval).
--d
In article <···········@news.gte.com>,
Dorai Sitaram <····@goldshoe.gte.com> wrote:
>In article <···············@world.std.com>,
>Kent M Pitman <······@world.std.com> wrote:
>>Ray Blaak <·····@infomatch.com> writes:
>>
>>> (let ((car (lambda (a) 'surprise)))
>>> (eval '(car (1 2))) ; 1 or surprise?
>>> (eval (list car 1 2))) ; 1 or surprise?
>>
>>Well, ignoring the problems with paren balancing and argument number here,
>>I assume the core of your question is whether the binding of CAR can
>>affect EVAL. In CL, it cannot, unless the binding is special, in which
>>case it always affects. But in any case the behavior is consistent.
>>
>>In Scheme, they don't have EVAL, so they have a kind of consistent
>>behavior, too. Perhaps partly because they would need to take list args,
>>not text.
>
>In Scheme they do have EVAL, and have had it for several
>years now. Vide R5RS (google for an online copy,
>and scan the index for eval).
EVAL was only added in the most recent revision. I think this probably
answers the original question: since Scheme didn't originally have EVAL or
COMPILE, it wasn't necessary to describe execution in terms of objects,
since there wasn't a standard way to execute an object. All you could do
was type expressions and compile or load files, both of which are textual.
When EVAL was added, they didn't go back and change the description to be
in terms of objects. Not much would be gained, so they left that part as
is.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
I took the liberty of modifying the example such that it was acceptable to CMUCL.
(let ((car (lambda (a) 'surprise)))
(print (eval '(car '(1 2))))
(print(eval (list 'car ''(1 2)))))
CMUCL result:
(let ((car (lambda (a) 'surprise)))
(print (eval '(car '(1 2))))
(print(eval (list 'car ''(1 2)))))
(LAMBDA (A) 'SURPRISE)
==>
#'(LAMBDA (A) 'SURPRISE)
Note: Variable A defined but never used.
(LET ((CAR #))
(PRINT (EVAL '#))
(PRINT (EVAL #)))
Note: Variable CAR defined but never used.
1
1
1
> Ray Blaak Writes:
> One thing I can think of is the avoidance of ambiguities of the meaning of the
> items being evaluated. Consider:
>
> (let ((car (lambda (a) 'surprise)))
> (eval '(car (1 2))) ; 1 or surprise?
> (eval (list car 1 2))) ; 1 or surprise?
>
> That is, does the meaning of what is being evaluated come from the symbols
> print names being evaluated in the local scope, or from the the item's value?
>
> By having scheme's formal syntax be in terms of text objects, things are
> clearly always evaluated in the local scope, and the "problem" does not arise.
>
> Not having a CL near me at the moment, what does CL do here?
>
> --
> Cheers, The Rhythm is around me,
> The Rhythm has control.
> Ray Blaak The Rhythm is inside me,
> ·····@infomatch.com The Rhythm has my soul.
>
> ------------------------------------------------------------------------
> Mailgate References:
> Lisp syntax : Lisp objects :: Scheme syn, Seth Gordon
> Re: Lisp syntax : Lisp objects :: Scheme, Kent M Pitman
> ------------------------------------------------------------------------
> [Previous] [Reply] [Index] [Home] [Find]
> Mailgate.ORG is maintained online by Dario Centofanti
--
Posted from [199.35.146.133]
via Mailgate.ORG Server - http://www.Mailgate.ORG
Erik Naggum <····@naggum.net> writes:
> * dave linenberg
> > I took the liberty of modifying the example such that it was acceptable
> > to CMUCL.
>
> Modifying away the variable reference to car is a modification that
> changes the semantics of the example quite dramatically in CL.
[...]
> All in all, this was an example that indeed highlights many important
> differences between Scheme and Common Lisp, all of them unintended by the
> author, who didn't have a clue how to write Common Lisp, which is also
> quite instructive.
Well, rusty would be more accurate, and becoming unrusty real fast :-).
> The lesson? Textually identical code have enormous differences in
> semantics between Scheme and Common Lisp, and Scheme people aren't even
> aware of it, hence their belief that Common Lisp and Scheme are similar.
> Arrogance from ignorance is immensely annoying.
Not guilty here.
My post had nothing to do with whether or not Scheme is better than CL or vice
versa (I withhold judgement on that matter, preferring, in this case, to learn
from the posts here).
I was only trying to point out a reason why Scheme's preference for describing
its grammar in terms of textual input might possibly make even the slightest
bit of sense. Note also that I am saying nothing about whether or not it is in
fact a good or bad idea.
But now I am curious about CL with regards to how eval finds things. Assuming
the following example is properly constructed, what would CL do here? (if I
had access to a CL right now, I would run this myself):
(defun foo () 'foo-in-toplevel)
(defpackage P)
(in-package P)
(defun foo () 'foo-in-P)
(defpackage Q)
(in-package Q)
(defun foo () 'foo-in-Q)
(defpackage Example)
(in-package Example)
(flet ((foo-in-P (progn (in-package P) (function foo)))
(foo (lambda () 'foo-in-let)))
(print (eval '(foo))) ; foo-in-let here?
(print (eval (list (function foo)))) ; ditto
(print (eval (list (function foo-in-P)))) ; foo-in-P? error?
(progn
(in-package P)
(print (eval '(foo))) ; foo-in-P here?
(print (eval (list (function foo))))) ; ditto
(progn
(in-package Q)
(print (eval '(foo))) ; foo-in-Q here?
(print (eval (list (function foo)))))) ; ditto
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> But now I am curious about CL with regards to how eval finds things. Assuming
> the following example is properly constructed, what would CL do here? (if I
> had access to a CL right now, I would run this myself):
>
> (defun foo () 'foo-in-toplevel)
>
> (defpackage P)
> (in-package P)
> (defun foo () 'foo-in-P)
>
> (defpackage Q)
> (in-package Q)
> (defun foo () 'foo-in-Q)
>
> (defpackage Example)
> (in-package Example)
>
> (flet ((foo-in-P (progn (in-package P) (function foo)))
> (foo (lambda () 'foo-in-let)))
> (print (eval '(foo))) ; foo-in-let here?
> (print (eval (list (function foo)))) ; ditto
> (print (eval (list (function foo-in-P)))) ; foo-in-P? error?
> (progn
> (in-package P)
> (print (eval '(foo))) ; foo-in-P here?
> (print (eval (list (function foo))))) ; ditto
> (progn
> (in-package Q)
> (print (eval '(foo))) ; foo-in-Q here?
> (print (eval (list (function foo)))))) ; ditto
>
Remember that the package system affects how symbols are interned at
*read time only*. So the only symbols in package P will be p::foo and
p::foo-in-p
The package forms in the body of the code will have no noticable
effect. Note, too, that all of *those* symbols are in the "example"
package, so you will mostly get unbound function errors.
EVAL pays no attention to the current lexical environment.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Tim Moore
Subject: Re: Lisp syntax : Lisp objects :: Scheme syntax : characters
Date:
Message-ID: <97er99$1a1$0@216.39.145.192>
On 26 Feb 2001, Ray Blaak wrote:
> Well, rusty would be more accurate, and becoming unrusty real fast :-).
This newsgroup is good for that, especially if you post code here.
> But now I am curious about CL with regards to how eval finds things. Assuming
> the following example is properly constructed, what would CL do here? (if I
> had access to a CL right now, I would run this myself):
eval only sees top-level bindings in CL. So the flet doesn't change
anything in your example.
Furthermore, you've muddied the waters (intentionally) with the package
stuff, but in-package doesn't change the behavior of the reader unless
it's at top level, so all the symbols in the flet form that aren't in
the COMMON-LISP package are in the EXAMPLE package. Since you never
defined a function foo at top-level in EXAMPLE, the evals would all be in
error.
My advice would be to get a free CL and try some code. Your
reintroduction to CL will go a lot smoother, and cause you a lot less
personal abuse, if you don't treat this newsgroup as a read-eval-print
loop :)
Tim
>
> (defun foo () 'foo-in-toplevel)
>
> (defpackage P)
> (in-package P)
> (defun foo () 'foo-in-P)
>
> (defpackage Q)
> (in-package Q)
> (defun foo () 'foo-in-Q)
>
> (defpackage Example)
> (in-package Example)
>
> (flet ((foo-in-P (progn (in-package P) (function foo)))
> (foo (lambda () 'foo-in-let)))
> (print (eval '(foo))) ; foo-in-let here?
> (print (eval (list (function foo)))) ; ditto
> (print (eval (list (function foo-in-P)))) ; foo-in-P? error?
> (progn
> (in-package P)
> (print (eval '(foo))) ; foo-in-P here?
> (print (eval (list (function foo))))) ; ditto
> (progn
> (in-package Q)
> (print (eval '(foo))) ; foo-in-Q here?
> (print (eval (list (function foo)))))) ; ditto
>
> --
> Cheers, The Rhythm is around me,
> The Rhythm has control.
> Ray Blaak The Rhythm is inside me,
> ·····@infomatch.com The Rhythm has my soul.
>
>
Joe Marshall <···@content-integrity.com> writes:
> EVAL pays no attention to the current lexical environment.
Tim Moore <·····@herschel.bricoworks.com> writes:
> eval only sees top-level bindings in CL. So the flet doesn't change
> anything in your example.
Thank you kindly.
> My advice would be to get a free CL and try some code. Your reintroduction
> to CL will go a lot smoother, and cause you a lot less personal abuse, if
> you don't treat this newsgroup as a read-eval-print loop :)
Sound advice.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.