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: [email protected] [mailto:[email protected]] > On Behalf Of Paul Ojanen > Sent: Saturday, August 21, 2010 8:17 AM > To: 'Eduardo Cavazos'; [email protected] > 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: [email protected] [mailto:users-boun...@racket- > lang.org] > > On Behalf Of Eduardo Cavazos > > Sent: Saturday, August 21, 2010 3:33 AM > > To: [email protected] > > 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
