[plt-scheme] redefinition in module

That's the way it works now, but the "language" position of a module
could be special. I'm not yet sure it's a good change, but I'm starting
to like Jos's idea.

With Jos's change, the module level would have a little more of the
oddness of internal definitions for certain cases. For example,

  (define define 5)

would be parsed as a definition that shadows further uses of `define',
but that doesn't affect the ones already expanded. In other words, a
programmer would have to reason about the order of expansion in a
module body to predict some bindings --- but that's already true in
cases that are less strange that defining `define'.

Changing the implementation is a little tedious, but it doesn't look
too difficult. I'll have to try it out and see whether I'm overlooking
a more serious problem.

Matthew

At Fri, 29 Feb 2008 15:44:24 -0600, "Robby Findler" wrote:
> A few minor points to add to the stew: "#lang scheme" should hopefully
> change at about the rate the old mzscheme language changed (ie, not
> that often) so I hope that that won't be a problem, but "#lang
> scheme/base" shoudl change much less frequently than that, so if you
> want to be careful about your imports, you might consider using it
> instead (and importing what you need beyond it).
> 
> As far as scope goes, the module system treats all requires (including
> the require of "scheme") as being in the same scope as the definitions
> in a module (after all, you can interleave them). So, that program is,
> in some sense, like this one: (letrec ((add1
> the-original-mzscheme-add1) (add1 sub1)) ...)
> 
> Robby
> 
> On Fri, Feb 29, 2008 at 1:04 PM, Jos Koot <jos.koot at telefonica.net> wrote:
> >
> >
> > #lang scheme (let ((add1 sub1)) (add1 3))
> > is perfecttly alright.
> >
> > #lang scheme (define add1 sub1) (add1 3)
> > is not accepted.
> >
> > Why?
> > The redefinition does no harm to any other imported procedure or macro.
> > That's the beauty of modules: being sure that your macros and procedures
> > cannot be corrupted by invoking modules.
> > The restriction forces me to rename procedures and syntaxes previously not
> > present, but now provided by #lang scheme.
> > For example, I had my own nice and more general version of syntax 'for'. I
> > no longer can import my own 'for' without renaming.
> > And I have to rename every invocation of my for in all modules requiring my
> > nice 'for'.
> > I think that redefinitions in a module must be allowed and must be
> > considered to be local to the module.
> >
> > Now what happens:
> > 1: You have a fine #lang scheme program.
> > 2: You download a new scheme whose #lang scheme happens to include a 'new'
> > procedure or syntax with the same name as used in your nice program.
> > 3: Or one of the required modules happens to do that.
> > 4: The program no longer can be compiled.
> >
> > Why? This is very much against the principle of scope, I think.
> > I cannot think of any implementation problem.
> >
> > Jos Koot.
> >
> >
> >
> >
> >
> >
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme