A few years ago there were flame wars here as to whether Scheme was Lisp
or not and if I remember correctly, E. said at the time that Scheme
resembled Algol more that CL as Scheme use exclusively static scoping (I
hope I remember correctly).
I believed him of course, but did not fully understand what that meant.
Is not static (or lexical) scoping generally regarded as safer and better
than dynamic scoping? What are the advantages of dynamic scoping if we do
not take the simplicity of implementation into account?
Please try to give a simple (idiotproof) explanation.
(BTW: The email address does not work any more.)
TIA,
JB
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi <······@hotmail.com> wrote in message news:<······························@hotmail.com>...
> A few years ago there were flame wars here as to whether Scheme was Lisp
> or not and if I remember correctly, E. said at the time that Scheme
> resembled Algol more that CL as Scheme use exclusively static scoping (I
> hope I remember correctly).
> I believed him of course, but did not fully understand what that meant.
>
> Is not static (or lexical) scoping generally regarded as safer and better
> than dynamic scoping?
It's regarded as better optimizeable.
> What are the advantages of dynamic scoping if we do
Program in Lisp for a year and you will see. The advantage of dynamic
scoping is---unsurprisingly---that you can access variables that are
local to your dynamic context without being physically confined to the
immediately enclosing program text.
Dynamic variables can, in a completely invisible way, pass arbitrary
information across nested function calls. Invisible means that the
intermediate functions in the chain are not involved in the data path;
they don't take any additional parameters which they have to pass
down. The entire dynamic environment with its dynamic bindings is
implicitly passed down.
> not take the simplicity of implementation into account?
What makes you think dynamic scoping is all that simple? For one
thing, in the presence of threads, the variable references have to be
thread specific. Each thread can independently override a dynamic
variable in its own dynamic contexts. This requires some measure of
support from the multithreading substrate.
> Please try to give a simple (idiotproof) explanation.
How about an example:
(let ((*print-base* 16))
(print 42)
(let ((*print-base* 10))
(print 42))
(print 42))
Output is:
2A
42
2A
Each LET block temporarily binds the standard special variable
*print-base* to a new value. This binding is visible to the PRINT
function, which renders the integer value in the specified base. When
the LET block terminates, the value of *print-base* is restored to
whatever it was outside of that block.
No parameter was passed to the PRINT function to specify base. If the
PRINT function were buried in some other code, it would still be
influenced. Here is another example:
(defun print-hello ()
(format t "hello, world~%"))
;; what if we want it to go to a string?
(with-output-to-string (*standard-output*)
(print-hello))
The output of the function is captured in a string which forms the
return value of the WITH-OUTPUT-TO-STRING form. We did not require the
cooperation of the PRINT-HELLO function. Transparently to that
function, we communicated our wish to the I/O library to have standard
output go to a string stream.
Needless to say, you can't do these tricks with lexical scoping,
because lexical scoping is completely devoid of the ``action at a
distance'' semantics; to influence anything lexically, you have to go
to that site and introduce your lexical bindings in the source code
which you must then recompile.
jblazi <······@hotmail.com> writes:
> Is not static (or lexical) scoping generally regarded as safer and better
> than dynamic scoping?
By most of my friends, yes. You're asking a statistical question that is
hard to answer in general.
> What are the advantages of dynamic scoping if we do
> not take the simplicity of implementation into account?
You never get anything for free. Conservation laws apply even to
language design. So, if safety is gained, what is lost? Ease of
bludgeoning others' code into doing what you need. (The flip side of
protection: "protection" protects the guy on the inside. Not so good
for the guy on the outside...)
That is, it's a rapid prototyping aid. You find that functions always
come with a bunch of -- I'll use the connotationally best word I can
find -- "felicitous" hooks into their behavior (you might read that as
"accidental" or "dangerous" if you are cynical) since you can't make
functions easily airtight except by making them never call any other
function... and even then you probably have to lock out interrupts.
Of course, you might say, you could communicate with the author and get
them to properly hook their code. Or you could use only open source.
The former takes time. The latter creates a source split. Once again,
my bottom line message: you never get anything for free.
Kent M Pitman <······@world.std.com> writes:
> jblazi <······@hotmail.com> writes:
>
> > Is not static (or lexical) scoping generally regarded as safer and better
> > than dynamic scoping?
> > What are the advantages of dynamic scoping if we do
> > not take the simplicity of implementation into account?
>
> You find that functions always
> come with a bunch of -- I'll use the connotationally best word I can
> find -- "felicitous" hooks into their behavior (you might read that as
> "accidental" or "dangerous" if you are cynical) since you can't make
> functions easily airtight except by making them never call any other
> function... and even then you probably have to lock out interrupts.
Btw, I wrote this thinking you'd meant "advantages as the default kind of
binding" not "advantages of having both vs of just having one".
Of course, in the case where you have both, you can advertise exactly
the hooks you want, and so everything doesn't end up "dangerous".
There is a tiny amount of danger even in documented specials, but it's
mostly outweighed by the benefit of being able to tune a program.
On Wed, 10 Sep 2003 14:56:42 -0400, Kent M Pitman wrote:
> Btw, I wrote this thinking you'd meant "advantages as the default kind of
> binding" not "advantages of having both vs of just having one".
>
> Of course, in the case where you have both, you can advertise exactly
> the hooks you want, and so everything doesn't end up "dangerous".
> There is a tiny amount of danger even in documented specials, but it's
> mostly outweighed by the benefit of being able to tune a program.
Thx. This is rather interesting. So having both types of typing gives you
complete control.
Would you consider CL's having both static and dynamic
scoping such an important feature of the language that you would say that
Scheme resembles Algol more than CL (as Scheme uses only static scoping as
a matter of principle)?
JB
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi <······@hotmail.com> writes:
> Would you consider CL's having both static and dynamic
> scoping such an important feature of the language that you would say that
> Scheme resembles Algol more than CL (as Scheme uses only static scoping as
> a matter of principle)?
Allow me to point out that any decent-sized Scheme system has
mechanisms for dynamic scope (usually called fluid-let in Scheme-land).
You need some abstraction for capturing the `ambient state' of the
world without explicitly passing it to every function in the world.
jblazi wrote:
> On Wed, 10 Sep 2003 14:56:42 -0400, Kent M Pitman wrote:
>
>>Btw, I wrote this thinking you'd meant "advantages as the default kind of
>>binding" not "advantages of having both vs of just having one".
>>
>>Of course, in the case where you have both, you can advertise exactly
>>the hooks you want, and so everything doesn't end up "dangerous".
>>There is a tiny amount of danger even in documented specials, but it's
>>mostly outweighed by the benefit of being able to tune a program.
>
>
> Thx. This is rather interesting. So having both types of typing gives you
> complete control.
Nitpick: You don't mean typing, you mean scoping. Typing is something
different.
> Would you consider CL's having both static and dynamic
> scoping such an important feature of the language that you would say that
> Scheme resembles Algol more than CL (as Scheme uses only static scoping as
> a matter of principle)?
No, I don't think so. It's relatively easy to implement dynamic scoping
in other languages. For example, Java has a similar concept called
"thread local" (see the ThreadLocal class). If you look at its
implementation you will find out that it is almost trivial to implement.
Common Lisp is a more or less a complete collection of best practices
gained from decades of experience with various Lisp dialects. The fact
that Common Lisp has included the notion of dynamic scoping in its
standard is just a reflection of the fact that it is actually useful in
practice.
AFAICT, most Scheme implementations provide at least one form of dynamic
scoping. It seems to me that many people outside the Lisp culture
consider dynamic scoping to be an evil thing because of its bad
reputation it has gotten when it was the default scoping mechanism.
That's why it seems to be more or less completely abandoned in
mainstream languages. However, for example I have seen reasonable
amounts of Java code that are in fact just tedious and error-prone
hand-written simulations of dynamic scoping. (For example the source
code for the Java compiler from JDK 1.3 upwards has lots of code like that.)
Indeed, dynamic scoping by default can lead to very hard to detect bugs.
You have to make a conscious decision for dynamic scoping for specific
cases and have to be aware of its consequences. That's why in Common
Lisp, dynamically scoped variables are specially marked by asterisks
around their names, or why in ISLISP a special mechanism is provided to
access dynamically scoped variables.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Wed, 10 Sep 2003 12:51:18 +0200, jblazi <······@hotmail.com> wrote:
> A few years ago there were flame wars here as to whether Scheme was
> Lisp or not and if I remember correctly, E. said at the time that
> Scheme resembled Algol more that CL as Scheme use exclusively static
> scoping (I hope I remember correctly). I believed him of course,
> but did not fully understand what that meant.
>
> Is not static (or lexical) scoping generally regarded as safer and
> better than dynamic scoping? What are the advantages of dynamic
> scoping if we do not take the simplicity of implementation into
> account?
>
> Please try to give a simple (idiotproof) explanation.
* (defun foo (x) (format t "Result: ~A" (* x x)))
FOO
* (with-output-to-string (*standard-output*) (foo 3))
"Result: 9"
FOO is a simple function which just prints to *STANDARD-OUTPUT*. But
because *STANDARD-OUTPUT* is dynamically scoped you can easily
"redirect" FOO's output to another stream without changing FOO.
See also
<http://www.flownet.com/gat/specials.pdf>
<http://cl-cookbook.sourceforge.net/io.html#redir>
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> On Wed, 10 Sep 2003 12:51:18 +0200, jblazi <······@hotmail.com> wrote:
>
> > A few years ago there were flame wars here as to whether Scheme was
> > Lisp or not and if I remember correctly, E. said at the time that
> > Scheme resembled Algol more that CL as Scheme use exclusively static
> > scoping (I hope I remember correctly). I believed him of course,
> > but did not fully understand what that meant.
> >
> > Is not static (or lexical) scoping generally regarded as safer and
> > better than dynamic scoping? What are the advantages of dynamic
> > scoping if we do not take the simplicity of implementation into
> > account?
> >
> > Please try to give a simple (idiotproof) explanation.
>
> * (defun foo (x) (format t "Result: ~A" (* x x)))
>
> FOO
> * (with-output-to-string (*standard-output*) (foo 3))
>
> "Result: 9"
>
> FOO is a simple function which just prints to *STANDARD-OUTPUT*. But
> because *STANDARD-OUTPUT* is dynamically scoped you can easily
> "redirect" FOO's output to another stream without changing FOO.
>
> See also
>
> <http://www.flownet.com/gat/specials.pdf>
> <http://cl-cookbook.sourceforge.net/io.html#redir>
>
> Edi.
The question is, whether that is a useful method to implement an API.
Problem: implement an API (functions, datatypes, ...) for writing to streams
What is a useful pattern to do that?
The Common Lisp 'solution': do almost everything at once.
- special printing functions that take some stuff as parameters and
other stuff from special variables (PRINC, ...)
- general printing functions that take a wide variety of parameters
and defaults from special variables for most/all (WRITE !!!)
- low-level printing functions (WRITE-CHAR, WRITE-BYTE, ...)
- generic function which specializes of stream and object and
also can look at special variables (PRINT-OBJECT, ...)
- printing function with special domain specific programming language and
compiler (FORMAT, FORMATTER)
So Common Lisp mixes happily all kinds of parameter passing
(required, optional, keyword, default-values, ...).
Sometimes STREAM is a keyword arg, sometimes it is the first required
arg, sometimes it is second and optional, ...
The last thing that is missing is the usage of printing context
objects (-> graphic contexts in CLIM).
I'm not really sure, whether the implicit shadowing/passing of
parameters via special variables is really a good pattern for
this problem. Ideas and discussions welcome.
Rainer Joswig
Edi Weitz <···@agharta.de> writes:
> FOO is a simple function which just prints to *STANDARD-OUTPUT*. But
> because *STANDARD-OUTPUT* is dynamically scoped you can easily
> "redirect" FOO's output to another stream without changing FOO.
This is particulary useful when you're not in a position to
change FOO at all, e.g. I use the following in lispworks to
pick up the output of the room function:
CL-USER 7 > (with-output-to-string (*standard-output*) (room nil))
"
Total Size 81702K, Allocated 44499K, Free 37041K
"
--
(espen)
* Espen Vestre <·····@*do-not-spam-me*.vestre.net>
| Edi Weitz <···@agharta.de> writes:
|
| > FOO is a simple function which just prints to *STANDARD-OUTPUT*. But
| > because *STANDARD-OUTPUT* is dynamically scoped you can easily
| > "redirect" FOO's output to another stream without changing FOO.
|
| This is particulary useful when you're not in a position to
| change FOO at all, e.g. I use the following in lispworks to
| pick up the output of the room function:
|
| CL-USER 7 > (with-output-to-string (*standard-output*) (room nil))
| "
| Total Size 81702K, Allocated 44499K, Free 37041K
| "
I do the same (with CMUCL) in my web server, see:
http://213.97.131.125/lisp/room
Hit refresh to see lisp image consing in real time :)
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
jblazi wrote:
> A few years ago there were flame wars here as to whether Scheme was Lisp
> or not and if I remember correctly, E. said at the time that Scheme
> resembled Algol more that CL as Scheme use exclusively static scoping (I
> hope I remember correctly).
> I believed him of course, but did not fully understand what that meant.
Yes, that is a general problem with gurus - people believe them although
they don't fully understand them.
For this particular example, it is again important to note that CL and
Scheme serve different communities. Schemers want a minimal language
with no unnecessary overhead. Since dynamic scoping can easily be
simulated on top of lexical scoping - with no real disadvantages - it
doesn't make sense to include it in a language that heads for
minimalism. (For example, one of the lambda papers by Sussman/Steele
illustrates a simulation.)
In a language that heads for completeness, the inclusion of dynamic
scoping makes perfect sense - that's why CL has it.
> Is not static (or lexical) scoping generally regarded as safer and better
> than dynamic scoping? What are the advantages of dynamic scoping if we do
> not take the simplicity of implementation into account?
That's not correct - lexical scoping is not generally safer and better
than dynamic scoping. It's only the safer and better _default_ scoping.
Lexical and dynamic scoping allow you to express different things. If
you don't care about the difference it's a good bet that lexical scoping
is what you want. If you care about it you can improve the design of
your code by sometimes going for dynamic scoping.
> Please try to give a simple (idiotproof) explanation.
The following paper is an overview with examples and references to other
papers: http://progwww.vub.ac.be/~wdmeuter/PostJava/Costanza.pdf
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza wrote:
> jblazi wrote:
>
>> Is not static (or lexical) scoping generally regarded as safer and better
>> than dynamic scoping? What are the advantages of dynamic scoping if we do
>> not take the simplicity of implementation into account?
>
> That's not correct - lexical scoping is not generally safer and better
> than dynamic scoping. It's only the safer and better _default_ scoping.
Is static scope and lexical scope the same thing, or is there differences
like the difference between strong typing and static typing?
--
--
Gisle S�lensminde
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no
On Wed, 10 Sep 2003 14:18:54 +0000, Gisle S�lensminde wrote:
> Is static scope and lexical scope the same thing, or is there differences
> like the difference between strong typing and static typing?
>
It is the same.
--,
JB
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Wed, 10 Sep 2003 15:20:48 +0200, Pascal Costanza wrote:
> The following paper is an overview with examples and references to other
> papers: http://progwww.vub.ac.be/~wdmeuter/PostJava/Costanza.pdf
Ok, thx to all of you.
But is it not true that the master looked down upon Scheme as it was a
statically scoped language? Or did I misunderstand Him? (And this was why
He said that Scheme was in reality more related to Algol than to CL?)
--,
JB
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
> On Wed, 10 Sep 2003 15:20:48 +0200, Pascal Costanza wrote:
> > The following paper is an overview with examples and references to other
> > papers: http://progwww.vub.ac.be/~wdmeuter/PostJava/Costanza.pdf
> Ok, thx to all of you.
> But is it not true that the master looked down upon Scheme as it was a
> statically scoped language? Or did I misunderstand Him? (And this was why
> He said that Scheme was in reality more related to Algol than to CL?)
One difference between scheme and algol is that Scheme gives you
everything
you need to implement dynamic scope if you want it, and Algol doesn't.
One
of the reasons why teachers like Scheme so much is that, by implementing
dynamic scope, they can show students the difference between dynamic and
lexical scope. When you just demonstrate the difference in a language
where
it's pre-built, some students won't "get it" because they don't see how
it
works.
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> One difference between scheme and algol is that Scheme gives you
> everything you need to implement dynamic scope if you want it
Really? How do you do it? (And in particular, how do you do it so it's
thread-safe?)
E.
Erann Gat wrote:
>
> In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
>
> > One difference between scheme and algol is that Scheme gives you
> > everything you need to implement dynamic scope if you want it
>
> Really? How do you do it? (And in particular, how do you do it so it's
> thread-safe?)
Honestly? I don't. I've never needed it. I have seen this bit of
wizardry/hackery over on CLS though from people who thought it was
indispensable, or just neat, which involved directly mutating and
accessing a single dynamic-environment structure that was defined
in the top-level lexical environment, giving it as an argument the
call-chain extant at the point of access so it could give them the
right dynamic environment frame. If you wanted it multithreaded,
I think the first approximation would be that you'd have to have a
separate call-chain variable encapsulated in it for each thread.
But multithreading's not standard and the implementation I saw didn't
use it. They implemented it, I guess, for the same reasons I
occasionally implement objects in scheme if some particular program
needs OO technique; it's a technique or usage pattern rather than
something directly provided and prepackaged.
Scheme is a language without the idea of what CL and C++ programmers
call "threads", although a lot of implementations provide them as an
extension and there's a proposed standard for multithreading scheme
now over on srfi.schemers.org. I don't happen to like this proposal,
but the people who are actually implementing software that really
needs to be multithreaded say that it does what they want and is
easier to use than doing it with continuations, so... they've got
a library or two now to do it with. What scheme has instead of
threading is fully re-entrant continuations, which are powerful,
especially in combination with fully general tail call optimization,
but very different.
I can handle threads, and actually like fully re-entrant continuations
- but the idea of handling both at once in the same program, especially
if running threads simultaneously on multiple CPU's, gives me the
jibblies about any meaningful use of the word 'safe.' I don't think
it's necessarily unsolvable, but I would not like to trust anyone's
implementation for "safety" in the presence of _both_ of these
constructs unless I knew that it had been specifically designed and
debugged for safety in the presence of _both_ constructs.
Bear
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
>
>> One difference between scheme and algol is that Scheme gives you
>> everything you need to implement dynamic scope if you want it
>
> Really? How do you do it? (And in particular, how do you do it so it's
> thread-safe?)
Monads.