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