Now I understand the concept of scoping.
you have a free variable you define in a lambda
expression ( which you bind to some variable,
otherwise it is useless later ).
You have two values that the free variable can
assume: the value of the variable at compile time,
the value of the variable at run time.
Now a small confession. I always get confused
which one is called dynamically scoped and
which one is called lexically scoped.
Now for a question which has piqued my curiousity:
a (named) function is simple a lambda expression
that is bound to a variable. To call that function,
you access it through the name of the variable.
Since a function is a variable, so it is scoped.
Now let us look at an example in emacs of a trick:
;; Sorry if the elisp is a bit off. It's been a while.
(setq old-foo foo)
(defun foo(x)
(let ((retval ""))
(message (format "Entering foo with argument %S" x))
(setq retval (old-foo x))
(message (format "Exiing foo with result %S" retval))
retval))
Which relies on the variable using it's value at runtime.
So the question is how are functions scoped in various implementation
of Lisp and Scheme?
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
TLOlczyk <··········@yahoo.com> writes:
> Now I understand the concept of scoping.
> you have a free variable you define in a lambda
> expression ( which you bind to some variable,
> otherwise it is useless later ).
>
> You have two values that the free variable can
> assume: the value of the variable at compile time,
> the value of the variable at run time.
>
> Now a small confession. I always get confused
> which one is called dynamically scoped and
> which one is called lexically scoped.
No. This has nothing to do with compile-time or runtime.
(eval-when (:compile-toplevel)
(defparameter *dyn* :compiling-dyn))
(eval-when (:load-toplevel)
(defparameter *dyn* :loading-dyn))
(defmacro m ()
(let ((lex :compiling-lex-in-macro))
(format t "~& At compilation time, *dyn* = ~S ~%" *dyn*)
(format t "~& At compilation time, lex = ~S ~%" lex))
`(let ((lex :running-lex-in-macro))
(format t "~& At run-time, *dyn* = ~S ~%" *dyn*)
(format t "~& At run-time, lex = ~S ~%" lex)));;m
(defun f ()
(let ((lex :running-lex-in-function))
(format t "~& At run-time, *dyn* = ~S ~%" *dyn*)
(format t "~& At run-time, lex = ~S ~%" lex))
(m));;f
(f)
;;;; dyn-lex-mac-fun.lisp -- -- ;;;;
[14]> (load (compile-file "dyn-lex-mac-fun.lisp"))
Compiling file /local/users/pascal/src/lisp/encours/dyn-lex-mac-fun.lisp ...
At compilation time, *dyn* = :COMPILING-DYN
At compilation time, lex = :COMPILING-LEX-IN-MACRO
Wrote file /local/users/pascal/src/lisp/encours/dyn-lex-mac-fun.fas
0 errors, 0 warnings
;; Loading file /local/users/pascal/src/lisp/encours/dyn-lex-mac-fun.fas ...
At run-time, *dyn* = :LOADING-DYN
At run-time, lex = :RUNNING-LEX-IN-FUNCTION
At run-time, *dyn* = :LOADING-DYN
At run-time, lex = :RUNNING-LEX-IN-MACRO
;; Loaded file /local/users/pascal/src/lisp/encours/dyn-lex-mac-fun.fas
T
Notes: a compilation-time and a load-time may very well NOT exist!
When you modify the running program at the REPL, unless you call
COMPILE to force compilation, you don't necessarily have any
compilation time, and you don't get a load time anyway:
[15]> (eval-when (:load-toplevel) (print :toto))
NIL
[16]> (defun g () (f))
G
[17]> (g)
At run-time, *dyn* = :LOADING-DYN
At run-time, lex = :RUNNING-LEX-IN-FUNCTION
At run-time, *dyn* = :LOADING-DYN
At run-time, lex = :RUNNING-LEX-IN-MACRO
NIL
[18]> (defun h () (m))
At compilation time, *dyn* = :LOADING-DYN
At compilation time, lex = :COMPILING-LEX-IN-MACRO
H
> Now for a question which has piqued my curiousity:
> a (named) function is simple a lambda expression
> that is bound to a variable. To call that function,
> you access it through the name of the variable.
But remember:
variable n. a binding in the ``variable'' namespace. See Section
3.1.2.1.1 (Symbols as Forms).
A variable IS a binding. A variable is only a relation between a name
and a value.
Most function are defined with a dynamic binding (defun ...).
But you can as well define functions with a lexical binding (flet ...)
or (label ...).
> Since a function is a variable, so it is scoped.
No a function is not a variable. A function is a function.
All these are functions:
[19]> (lambda (x) (1+ x))
#<CLOSURE :LAMBDA (X) (1+ X)>
[20]> (symbol-function 'car)
#<SYSTEM-FUNCTION CAR>
[21]> (symbol-function 'g)
#<CLOSURE G NIL (DECLARE (SYSTEM::IN-DEFUN G)) (BLOCK G (M))>
The first one is not bound to any name. (It is not a variable).
> Now let us look at an example in emacs of a trick:
>
> ;; Sorry if the elisp is a bit off. It's been a while.
> (setq old-foo foo)
> (defun foo(x)
> (let ((retval ""))
> (message (format "Entering foo with argument %S" x))
> (setq retval (old-foo x))
> (message (format "Exiing foo with result %S" retval))
> retval))
>
> Which relies on the variable using it's value at runtime.
Emacs has no lexical scoping. Assume that all variable x in emacs
has a corresponding declaration: (declare (special x)).
> So the question is how are functions scoped in various implementation
> of Lisp and Scheme?
Emacs lisp has no flet or label either (*). All binding in emacs is
dynamic, be it a value or a function binding.
(*) There are flet and label macros implemented in cl extensions of
emacs (require 'cl) that hare heavily frowned upon by the authors
of emacs (up to the point of having a warning in the compiler when
you use them!). But they are implemented the hard way over emacs
lisp, like you could implement a Modula-3 compiler in emacs-lisp...
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Most function are defined with a dynamic binding (defun ...).
That's not true. DEFUN establishes a _global_ binding. It cannot be
shadowed dynamically in separate threads with different values. It can
only be _modified_ temporarily or permanently. Dynamic AOP (implemented
by the other Pascal, if I'm not mistaken) gives you the ability to
dynamically bind a function, conceptually, but it achieves this by
replacing the global function binding with one that FUNCALLs the value
of a dynamic variable.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On 28 Mar 2004 12:30:30 +0200, Pascal Bourguignon
<····@thalassa.informatimago.com> wrote:
>TLOlczyk <··········@yahoo.com> writes:
>
>> Now I understand the concept of scoping.
>> you have a free variable you define in a lambda
>> expression ( which you bind to some variable,
>> otherwise it is useless later ).
>>
>> You have two values that the free variable can
>> assume: the value of the variable at compile time,
>> the value of the variable at run time.
>>
>> Now a small confession. I always get confused
>> which one is called dynamically scoped and
>> which one is called lexically scoped.
>
>No. This has nothing to do with compile-time or runtime.
No. A confusion of terminology is involved here.
By compile-time I mean the time that the lambda expression
is created and bound to the variable name.
By run-time I mean the time that the lambda expression is
evaluated.
Look at the folowing code:
(let ((x 4))
(defun make_foo()
(lambda (y)
(+ x y))))
(let ((temp_foo (make_foo)))
(defun foo(y)
(funcall temp_foo y)))
(setq res (list (foo 4)))
(setf x 3)
(setf res (append res (list (foo 4))))
(setf x 0)
(let ((temp_foo (make_foo)))
(defun foo2(y)
(funcall temp_foo y)))
(setf res (append res (list (foo2 4))))
(Let ((xx 4))
(declare (special xx))
(defun make_fooII()
(lambda (y)
(+ xx y))))
(let ((temp_foo (make_fooII)))
(defun foo3(y)
(funcall temp_foo y)))
;; Have to add this line below because xx
;; is not bound to anything.
(setf xx 4)
(setf res (append res (list (foo3 4))))
(setf xx 3)
(setf res (append res (list (foo3 4))))
(setf xx 0)
(let ((temp_foo (make_fooII)))
(defun foo4(y)
(funcall temp_foo y)))
(setf res (append res (list (foo4 4))))
res
Which produces:
(8 8 8 8 7 4)
There are two variables which are scoped differently:
x ( lkexically scoped ) which assumes the
value 4 which is the value of x at compile time ( when the defun
is evaluated ).
xx (dynamically scoped ) which assumes the value 4,3 0
depending on when the expression (foo* 4) is evaluted
( runtime ).
>> Now for a question which has piqued my curiousity:
>> a (named) function is simple a lambda expression
>> that is bound to a variable. To call that function,
>> you access it through the name of the variable.
>
>But remember:
>
> variable n. a binding in the ``variable'' namespace. See Section
> 3.1.2.1.1 (Symbols as Forms).
>
>A variable IS a binding. A variable is only a relation between a name
>and a value.
>
No. As an example, given the (lambda) expression (In TeX )
\lambda x.(x+y), x is a bound variable y is a free variable.
>
>Most function are defined with a dynamic binding (defun ...).
>
>But you can as well define functions with a lexical binding (flet ...)
>or (label ...).
>
>
In other words the scope of a function depends on how it is bound,
different bindings lead to different scope. Fair enough.
>> Since a function is a variable, so it is scoped.
>
>No a function is not a variable. A function is a function.
>
In the lambda expression above either x or y can be lambda
expressions. In fact can write the lambda expression
\lambda x, f x. where f is a variable "attached" to a lambda
expression. So I guess functions are variables.
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
TLOlczyk wrote:
> (let ((x 4))
> (defun make_foo()
> (lambda (y)
> (+ x y))))
...
> There are two variables which are scoped differently:
> x ( lkexically scoped ) which assumes the
> value 4 which is the value of x at compile time ( when the defun
> is evaluated ).
The connection you're making between scoping and the values which variables
take on doesn't seem to be correct.
Scoping merely determines which definition is associated with references to
a variable, and where references to a variable are allowed. For example,
with lexically scoped variables, you know that the definition of a variable
must occur earlier in the same expression as any reference to that variable.
Outside of that expression, a lexical variable is not visible, i.e.
references to it are not possible.
There's no real distinction between different types of variables in terms of
when they are initialized to their values. In the above excerpt from your
example, x could be a dynamic variable, and that code fragment would have
the same behavior. In particular, the actual value of x would be determined
at the exact same time in both cases. If we ignore compiler optimizations
for constant expressions, this initialization has to happen at runtime.
The difference if x is dynamic would be that since x would be visible from
other places, something external might change its value.
> xx (dynamically scoped ) which assumes the value 4,3 0
> depending on when the expression (foo* 4) is evaluted
> ( runtime ).
Again, you could set up something similar with a lexical version of xx,
simply by wrapping the entire program in a let which defines xx. The same
results could be achieved. The scope of the variable merely affects where
references to it are valid.
> > variable n. a binding in the ``variable'' namespace. See Section
> > 3.1.2.1.1 (Symbols as Forms).
> >
> >A variable IS a binding. A variable is only a relation between a name
> >and a value.
> >
> No. As an example, given the (lambda) expression (In TeX )
> \lambda x.(x+y), x is a bound variable y is a free variable.
In most Lisps, a free variable reference is an error. You can have free
variables in lambda calculus, but the meaning of an expression containing a
free variable depends on determining the status of that variable.
In Lisp, references to apparently free variables would normally be
interpreted as being references to variables with indefinite scope (e.g.
global or dynamic variables). If, at runtime, an attempt to find the
binding of such a variable fails, you get an error.
An area of possible terminology confusion here are the different meanings of
the terms 'bound' and 'binding'. In the expression (let ((x 4)) x), we say
x is bound to 4, or that a binding is created in which x=4. The expression
(let ((x 4)) ...) is equivalent to ((lambda (x) x) 4). The binding in this
case, of x to 4, is created by a function application (conceptually, if not
actually in a particular Lisp implementation). But if we look only at the
expression (lambda (x) x), we also say that the variable x is bound in this
expression. Here, we're not talking about the specific value to which x is
bound, but rather that references to the variable x in the body, are
references to the same x which is specified as a function parameter. You
can think of the former sort of binding, x=4, as being an instance of the
latter sort.
This latter use of the term "bound" is what can be determined at compile
time - so, for example, a lexical variable reference can be compiled into an
access to a particular relative stack location. This doesn't affect the
actual value that a variable ultimately receives, at runtime.
If you're going to be thinking about these things in terms of lambda
calculus, you might find Scheme easier to get started with than Common Lisp.
> >Most function are defined with a dynamic binding (defun ...).
> >
> >But you can as well define functions with a lexical binding (flet ...)
> >or (label ...).
> >
> >
> In other words the scope of a function depends on how it is bound,
> different bindings lead to different scope. Fair enough.
Afaict, you're not talking about the scope of a function here, you're
talking about the scope of the variables which are bound to those functions.
This might seem like a picky point, but in this discussion, it's an
important distinction.
> >> Since a function is a variable, so it is scoped.
> >
> >No a function is not a variable. A function is a function.
> >
> In the lambda expression above either x or y can be lambda
> expressions. In fact can write the lambda expression
> \lambda x, f x. where f is a variable "attached" to a lambda
> expression. So I guess functions are variables.
No. Variables are variables - names which stand for something - and
functions are functions. In the function \x. f x, f is a name for a
function, it is not "itself" a function.
People speak loosely all the time, and talk about "the scope of a function"
when they mean the scope of the variable which refers to a function, or talk
about "the append function" when they mean the function referred to by the
variable "append". But if you're trying to understand things at the level
of binding and scope, you need to be clear about the distinctions between
variables and values, at the very least.
Anton
TLOlczyk <··········@yahoo.com> wrote in message news:<··································@4ax.com>...
> The reply-to email address is ··········@yahoo.com.
> This is an address I ignore.
> To reply via email, remove 2002 and change yahoo to
> interaccess,
>
> **
> Thaddeus L. Olczyk, PhD
>
> There is a difference between
> *thinking* you know something,
> and *knowing* you know something.
Pascal already answered this, so I won't. I'm just curious, how can
someone with a PhD ask such naive questions (if you don't mind my
asking, of course)? You are also pretty confused about terminology
(scoping vs namespaces), and it seems that you *aren't* new to Lisp.
What gives?
·············@yahoo.com (David Fisher) writes:
> TLOlczyk <··········@yahoo.com> wrote in message news:<··································@4ax.com>...
>
>> The reply-to email address is ··········@yahoo.com.
>> This is an address I ignore.
>> To reply via email, remove 2002 and change yahoo to
>> interaccess,
>>
>> **
>> Thaddeus L. Olczyk, PhD
>>
>> There is a difference between
>> *thinking* you know something,
>> and *knowing* you know something.
>
>
> Pascal already answered this, so I won't. I'm just curious, how can
> someone with a PhD ask such naive questions (if you don't mind my
> asking, of course)? You are also pretty confused about terminology
> (scoping vs namespaces), and it seems that you *aren't* new to Lisp.
> What gives?
Troll. Try google.
--
~jrm
Follow-ups to comp.soft-sys.ace so that people can confirm or deny my
claims about Doug Schmidt. ( I've not included it in follow-ups. )
On 28 Mar 2004 16:19:06 -0800, ·············@yahoo.com (David Fisher)
wrote:
>Pascal already answered this, so I won't. I'm just curious, how can
>someone with a PhD ask such naive questions (if you don't mind my
>asking, of course)?
There are really three statements here that make up your overall
question.
The first is the statements that my question was naive. If it is such
a simple question, then perhaps you can answer the following question.
Why Pascal had to give such a lengthly answer? An answer so lengthly
that I am waiting to finish putting my printer back together to
print the answer rather than using a newsreader.
Perhaps you can point to the sections in Feldman&Felleisen, Winston
& Horn or Grahams's ACL? Since the question is so naive, I presume
that the answer is in the first few chapters.
The second statement is that PhDs shouldn't ask naive questions.
Which just goes to show how little you know about learning. I
earned my PhD precisely because I was willing to ask stupid questions.
Others around me failed because they never asked the questions
and thus never understood. They learned more and more based
on misunderstanding, till they learned so much based on
misunderstandings that they were totally confused.
The third statement is that you expect PhDs to know Lisp ( since
a question about Lisp can only be naive if the person knows Lisp ).
The first reaction is that something 99% of the PhDs out there know
*no* programming language. And that at 50% don't even know
how to use a computer.
But of the 1% who do know a programming language, and of the fewer
whose doctorate has some focus in programming, Lisp is nowhere near
a requirement, and I find it a bit arrogant to assume that it is.
Doug Schmidt, for example, has a PhD, and from what I know of his
background, it is not necessarily true that he has ever had any
exposure to Lisp. I dare say that the same is true of Ralph Johnson.
Fact is that when it comes to CS and CS related degrees there are
probably more people who have not learned Lisp than there are who
have.
>You are also pretty confused about terminology
>(scoping vs namespaces), and it seems that you *aren't* new to Lisp.
>What gives?
Hmm. Considering that the question was partially about Scheme and
elisp, and considering that even in Lisp scoping and namespaces are
orthogonal concepts (scoping is about how/when names are bound to
values and namespaces is about where names are bound to values ), and
considering that my question is precisely about how/when name are
bound to values, I would guess that my terminology is not confused.
Sure there is the fact that I use the term variable as it it used in
lambda calculus instead of the way it is used in Lisp, are you saying
that Lisp programmers think lambda calculus is somehow confused?
As for why I ask, well I was thinking about constructions such as
this and was wondering how Lisp supported simiar constructions.
let f x=x +1;;
let make_g x =2 *( f x);;
let g x =make_g x;;
let f x=x+2;;
let g2 x=make_g x;;
g 4;;
g2 4;;
let f=ref(fun x->x+1);;
let make_g=2* (!f x);;
let g x =make_g x;;
f:=fun x->x+2;;
let g2 x=make_g x;;
g 4;;
g2 4;;
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
TLOlczyk <··········@yahoo.com> wrote in message news:<··································@4ax.com>...
> Doug Schmidt, for example, has a PhD, and from what I know of his
> background, it is not necessarily true that he has ever had any
> exposure to Lisp. I dare say that the same is true of Ralph Johnson.
I think the point here is that if Doug Schmidt had the same history of
trolling the Lisp newsgroup, he'd have a clue about lexical variables
by now.
Hi Folks,
>> Doug Schmidt, for example, has a PhD, and from what I know of his
>> background, it is not necessarily true that he has ever had any
>> exposure to Lisp.
Actually, I wrote a global register allocation program in Lisp in my
AI class as a grad student at UCI in 1990. I enjoyed it quite a bit,
though I have a feeling I wrote it more like a C/C++ programmer than a
true Lisper ;-)
>> Fact is that when it comes to CS and CS related degrees there are
>> probably more people who have not learned Lisp than there are who
>> have.
That's certainly been my experience too!
Take care,
Doug
--
Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/
Nashville, TN 37203 NET: ·········@vanderbilt.edu
Thaddeus, I called your questions naive because, well, anyone who
studied CS should probably know what lexical variables are (even *if*
not, it's _faster_ to look up the definition in Wikipedia or something
than to ask). Secondly, in your examples, you were binding variables
in one namespace, then making conclusions about the scoping in the
other namespace.
Anyway, this table should summarize some scoping/namespacing issues in
CL and Scheme:
+------------------------------------------------+
| scoping | namespace |
| |--------------------------------------|
| | 1st | 2nd |
|---------+---------------------------+----------|
| lexical | let (unless the varialbe | flet |
| | is already dynamic) | macrolet |
| | | defun |
| | define (Scheme) | defmacro |
|---------+---------------------------+----------|
| dynamic | defparameter | |
| | defvar (default in CMUCL) | |
+------------------------------------------------+
DECLARE'ations can alter the dynamic/lexical property.
So, my surprise wasn't that you didn't remember these factoids (I
might have gotten them wrong myself), but <what I said above>. I was
prodding you to say "My Ph.D. is an honorary one, in humanities" (or
something like that). Alas...
I'm not too sure about Emacs Lisp and ML. I believe everything is
dynamic in it, and the scoping is the same as in CL.
In your ML example, in addition to scoping and namespacing, another
orthogonal concept is involved: mutability. Variables are mutable in
Lisps, immutable in ML (only values are). DEFINE and DEFUN *mutate*
the variables, while LET (in all languages) just creates a new lexical
binding.
I'm very busy at work these days, I hope what I wrote won't require
corrections or further clarifications (by me anyway). Otherwise, email
your questions directly to Barry Margolin :-)
>>> I dare say that the same is true of Ralph Johnson.
You'd be surprised. Ask him about his time at Cornell.
In any case, he knows Smalltalk and that's almost okay.
-- Matthias :-)
P.S. Please take a look at Essentials of Programming Languages (first section on
interpreters) or http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/ .
TLOlczyk <··········@yahoo.com> wrote:
> The second statement is that PhDs shouldn't ask naive questions.
> Which just goes to show how little you know about learning. I
> earned my PhD precisely because I was willing to ask stupid questions.
> Others around me failed because they never asked the questions
> and thus never understood. They learned more and more based
> on misunderstanding, till they learned so much based on
> misunderstandings that they were totally confused.
True. It's better to ask naive questions than to believe
stupid answers, and it's far better to ask naive questions
than to provide the stupid answers.
If it weren't for the naive questions, how would we recognize
the stupidity of our answers?
Will
TLOlczyk <··········@yahoo.com> wrote in message news:<··································@4ax.com>...
> Now I understand the concept of scoping.
> you have a free variable you define in a lambda
> expression ( which you bind to some variable,
> otherwise it is useless later ).
>
> You have two values that the free variable can
> assume: the value of the variable at compile time,
> the value of the variable at run time.
>
> Now a small confession. I always get confused
> which one is called dynamically scoped and
> which one is called lexically scoped.
http://www.gnu.org/software/guile/docs/guile-ref/About-Closure.html#About%20Closure
is a very good overview of scoping in Scheme.
--Don