Actually, what *I* had in mind was the changing the fact that
you can't create a module except as a side effect of an import
statement, and you can't do much to modify them ( well, you
can with obscure tricks, but you're not really supposed to! ).
Since some of the desire for anonymous functions and/or nested
function definition were due to wanting to try to avoid
cluttering up the exported name space with local function,
perhaps a module statement could help manage namespace
by making it easy to create sub-name-spaces:
module xxx:
prompt = "Hello, sailor!"
def yyy():
...
I don't think THAT part of the scheme should be very controversial,
but adding other functions to manipulate environments ( like real
versions of my bind() and merge(), etc. ) might be, and I haven't
thought out the implications myself.
An "internal" module can be sort of simulated by a Class, but it
makes the intent a bit obscure, so I noted with interest your
comment:
>
> I have also thought of somehow unifying modules and classes, since
> most of the implementation of modules is duplicated for classes
> (though not the other way around). Then the "require" statement could
> manipulate the list of base classes (which would have to be turned
> into a list since tuples cannot be extended).
>
> Unsure-how-this-will-help-solving-the-lambda-problem,
>
Unsure-how-Tim-like-sig's-got-to-be-a-REQUIREMENT,
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics