Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #61289 > unrolled thread

Origin of eval()-ing in separate namespace object

Started byKalinni Gorzkis <musicdenotation@gmail.com>
First post2013-12-08 17:35 +0700
Last post2013-12-08 08:39 -0800
Articles 4 — 3 participants

Back to article view | Back to comp.lang.python


Contents

  Origin of eval()-ing in separate namespace object Kalinni Gorzkis <musicdenotation@gmail.com> - 2013-12-08 17:35 +0700
    Re: Origin of eval()-ing in separate namespace object rusi <rustompmody@gmail.com> - 2013-12-08 05:45 -0800
      Re: Origin of eval()-ing in separate namespace object Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-12-08 16:39 +0200
        Re: Origin of eval()-ing in separate namespace object rusi <rustompmody@gmail.com> - 2013-12-08 08:39 -0800

#61289 — Origin of eval()-ing in separate namespace object

FromKalinni Gorzkis <musicdenotation@gmail.com>
Date2013-12-08 17:35 +0700
SubjectOrigin of eval()-ing in separate namespace object
Message-ID<mailman.3727.1386506211.18130.python-list@python.org>
By which languages(s) Python was inspired to support evaluating expressions and executing statements in a separate “namespace” object?

This syntax:
eval(expression,globals) or exec(code,globals)
What is the origin of the functionality provided by the globals argument?

[toc] | [next] | [standalone]


#61290

Fromrusi <rustompmody@gmail.com>
Date2013-12-08 05:45 -0800
Message-ID<05d1151c-ee29-4631-bdeb-24102f527815@googlegroups.com>
In reply to#61289
On Sunday, December 8, 2013 4:05:54 PM UTC+5:30, Kalinni Gorzkis wrote:
> By which languages(s) Python was inspired to support evaluating expressions and executing statements in a separate “namespace” object?

> This syntax:
> eval(expression,globals) or exec(code,globals)
> What is the origin of the functionality provided by the globals argument?

Been here since the days of scheme at least
http://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29

For the record lisp was conceptualized in the late 50s and implemented
by 1960.  By the 80s it was widely regarded as the premier AI language
but it was also clear to users that the scoping rules were terribly
wrong.  So a number of the then lisps coalesced and re-separated into
2 major dialects -- scheme and common lisp.

I expect it -- 2 argument eval -- goes all the way back to the earliest lisp 
but Ive not access to the history.

[toc] | [prev] | [next] | [standalone]


#61295

FromJussi Piitulainen <jpiitula@ling.helsinki.fi>
Date2013-12-08 16:39 +0200
Message-ID<qotfvq3tnis.fsf@ruuvi.it.helsinki.fi>
In reply to#61290
rusi writes:

> On Sunday, December 8, 2013 4:05:54 PM UTC+5:30, Kalinni Gorzkis wrote:
>
> > By which languages(s) Python was inspired to support evaluating
> > expressions and executing statements in a separate "namespace"
> > object?
> 
> > This syntax:
> > eval(expression,globals) or exec(code,globals)
> > What is the origin of the functionality provided by the globals
> > argument?
> 
> Been here since the days of scheme at least
> http://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29
> 
> For the record lisp was conceptualized in the late 50s and
> implemented by 1960.  By the 80s it was widely regarded as the
> premier AI language but it was also clear to users that the scoping
> rules were terribly wrong.  So a number of the then lisps coalesced
> and re-separated into 2 major dialects -- scheme and common lisp.
> 
> I expect it -- 2 argument eval -- goes all the way back to the
> earliest lisp but Ive not access to the history.

Yes. From p. 13 of LISP 1.5 Programmer's Manual (the preface is dated
in 1962):

# _evalquote_ is defined by using two main functions, called _eval_
# and _apply_. _apply_ handles a function and its arguments, while
# _eval_ handles forms. Each of these functions also has another
# argument that is used as an association list for storing the values
# of bound variables and function names.

That association list is the namespace. _eval_ and _apply_ pass it
around and extend it as they call each other to evalute code.

So it seems that at least the idea of an explicit namespace argument
was there from the start. Mistakes related to the original dynamic
scoping continued to be made.

[toc] | [prev] | [next] | [standalone]


#61299

Fromrusi <rustompmody@gmail.com>
Date2013-12-08 08:39 -0800
Message-ID<a0796ed2-8334-4031-9b8c-5a32f88347b8@googlegroups.com>
In reply to#61295
On Sunday, December 8, 2013 8:09:39 PM UTC+5:30, Jussi Piitulainen wrote:
> rusi writes:

> > On Sunday, December 8, 2013 4:05:54 PM UTC+5:30, Kalinni Gorzkis wrote:
> > > By which languages(s) Python was inspired to support evaluating
> > > expressions and executing statements in a separate "namespace"
> > > object?
> > > This syntax:
> > > eval(expression,globals) or exec(code,globals)
> > > What is the origin of the functionality provided by the globals
> > > argument?
> > Been here since the days of scheme at least
> > http://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29
> > For the record lisp was conceptualized in the late 50s and
> > implemented by 1960.  By the 80s it was widely regarded as the
> > premier AI language but it was also clear to users that the scoping
> > rules were terribly wrong.  So a number of the then lisps coalesced
> > and re-separated into 2 major dialects -- scheme and common lisp.
> > I expect it -- 2 argument eval -- goes all the way back to the
> > earliest lisp but Ive not access to the history.

> Yes. From p. 13 of LISP 1.5 Programmer's Manual (the preface is dated
> in 1962):

> # _evalquote_ is defined by using two main functions, called _eval_
> # and _apply_. _apply_ handles a function and its arguments, while
> # _eval_ handles forms. Each of these functions also has another
> # argument that is used as an association list for storing the values
> # of bound variables and function names.

Heh – I am nostalgia-fied!

Wrote a Lisp interpreter as a student degree project in 1986.
Tried to use the Lisp 1.5 manual then but it was too archaic for me to
understand.  So mostly chewed on the UCI Lisp manual.  Took me some
years to understand that dynamic scoping was not my mistake but Lisp's!!

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web