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: [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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
