[racket] Nested scope in D vs Racket

The entire justification of the D design sounds like an essay 
by Hansen in 1980 on why nested scope is bad and modules (= files +.h)
is all you need. 

It's not about teaching, it's about freedom of expression. 
This is one of the least problems for programmers and I can't 
think of a bug I have seen that involved this issue. 


On Aug 21, 2010, at 8:57 AM, Paul Ojanen wrote:

> Hmm...I think I missed a distinction in modularity.  The quote says nested
> scopes don't directly aid in providing separate library file modularity.
> But the abstraction example I used was inner function modularity which does
> not span multiple files.
> 
> The given rationale makes sense only in the context of multi-file
> modularity?
> 
> -Paul
> 
>> -----Original Message-----
>> From: users-bounces at racket-lang.org [mailto:users-bounces at racket-lang.org]
>> On Behalf Of Paul Ojanen
>> Sent: Saturday, August 21, 2010 8:17 AM
>> To: 'Eduardo Cavazos'; users at racket-lang.org
>> Subject: Re: [racket] Nested scope in D vs Racket
>> 
>> How about these two points from the referenced rationale:
>> 
>> 1. "Allowing global symbol masking is necessary for writing good modular
>> code that's assembled out of separately compiled parts..."
>> 
>> 2. "...enclosing-scope masking is useless as a modularity device..."
>> 
>> 
>> #1 What exactly is global symbol masking?
>> I have been forced to learn the options of require due to naming
>> conflicts.
>> Is this global masking not being allowed?  Or are my require conflicts
>> problematic because my imported identifiers are coming in AT THE SAME
>> LEVEL?
>> Perhaps global symbol masking says you are allowed to shadow only global
>> variables, but not globally.  That is, global variables can be shadowed
>> but
>> only from within a nested scope.
>> 
>> #2 I get the impression that Racket/HtDP thinks opposite to the second
>> quote.  local is given a lot of detailed attention in Intermezzo 3 of
>> HtDP/1e, which ends by discussing nested scopes and demonstrating name
>> reuse.  local is important for abstraction and, due to the importance of
>> meaningful variable names, I would say enclosing-scope masking is very
>> important as a feature.  Not necessary but certainly not useless.
>> 
>> -Paul
>> 
>>> -----Original Message-----
>>> From: users-bounces at racket-lang.org [mailto:users-bounces at racket-
>> lang.org]
>>> On Behalf Of Eduardo Cavazos
>>> Sent: Saturday, August 21, 2010 3:33 AM
>>> To: users at racket-lang.org
>>> Subject: [racket] Nested scope in D vs Racket
>>> 
>>> Hello,
>>> 
>>> The first example in this note is illegal in the D programming language:
>>> 
>>> http://lists.puremagic.com/pipermail/digitalmars-d/2010-
>> August/081424.html
>>> 
>>> Coming from a Scheme background, I was surprised as this is allowed in
>>> Scheme. I.e. this is the quivalent code in Scheme:
>>> 
>>> (let ((a 20))
>>>   (let ((a 30))
>>>     ...))
>>> 
>>> Andrei Alexandrescu pointed out the rationale for this design decision
>>> here:
>>> 
>>> http://lists.puremagic.com/pipermail/digitalmars-d/2010-
>> August/081430.html
>>> 
>>> It sounds like the D designers are "protecting" the programmers. The
>>> Racket team is of course concerned with the "teachability" of their
>>> languages and have experience with the known pitfalls in languages. So
>>> my question is, do any Racket people agree with the rationale provided
>>> by the D guys? In all your years of teaching Scheme/Racket, has this
>>> situation of shadowing names been a problem? (I've always seen it as a
>>> feature, even C supports it.)
>>> 
>>> Ed
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/users
>> 
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/users
> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users