Lisp syntax : Lisp objects :: Scheme syntax : characters 
Author Message
 Lisp syntax : Lisp objects :: Scheme syntax : characters


Quote:
> 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



Tue, 12 Aug 2003 23:03:03 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:


> > 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.



Wed, 13 Aug 2003 09:54:39 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:


> > > 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,



Sat, 16 Aug 2003 02:29:05 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:

> 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.

Quote:
>   (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.



Sat, 16 Aug 2003 03:28:47 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters


Quote:

>>   (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



Sat, 16 Aug 2003 05:06:02 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters
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

Quote:
> 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,

>   ------------------------------------------------------------------------
> 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


Sat, 16 Aug 2003 05:12:46 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:

> * 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 :-).

Quote:
>   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,



Sat, 16 Aug 2003 07:12:31 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:




>>>   (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.

--

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.



Sat, 16 Aug 2003 07:29:58 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:




> > > > 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  



Sat, 16 Aug 2003 06:42:43 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:

> 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! =-----



Sat, 16 Aug 2003 07:52:37 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:
> Well, rusty would be more accurate, and becoming unrusty real fast :-).

This newsgroup is good for that, especially if you post code here.

Quote:
> 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

Quote:

> (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,




Sat, 16 Aug 2003 08:10:17 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:

> EVAL pays no attention to the current lexical environment.

> eval only sees top-level bindings in CL.  So the flet doesn't change
> anything in your example.

Thank you kindly.

Quote:
> 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,



Sat, 16 Aug 2003 08:36:50 GMT  
 Lisp syntax : Lisp objects :: Scheme syntax : characters

Quote:

> 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,



Sat, 16 Aug 2003 08:45:49 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. scheme/lisp syntax [Re: scheme]

2. New to Lisp question: advantages of Lisp syntax?

3. Lisp syntax and code as data (was: Re: scheme)

4. Lisp syntax and code as data (was: Re: scheme)

5. Object Oriented Scheme (RE: Alternative Syntax for Scheme)

6. Implementing letrec-syntax using only let-syntax and syntax-rules

7. Lisp syntax for ocaml?

8. Lisp syntax for Haskell?

9. "Lisp" syntax differences

10. Apple's Dylan environment and Lisp-like syntax

11. LISP syntax?

12. Infix/Prefix and Lisp Syntax

 

 
Powered by phpBB® Forum Software