[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question with binding

    I just have one question for anyone that's in favor of redefinition.

    Are you saying you want redefinition-with-wild-abandon?  I.e. do
    you NOT want the system to warn you and ask you: "Are you sure?"?
    (Admittedly there could be a hackerish thrill in living
    dangerously....safety is wimps. :-)

    Or, do you want the system to ask you?  (Which could be annoying,
    especially for loading files.)

    Or, do you want the system to warn you by default, unless you set
    a global-dont-warn-me-about-redefinitions flag appropriately?
    (And if the latter, are you prepared to have zillions of such
    global variables for similar things in a BIG MOBY system?)

There are other possibilities besides global switches and annoying

In MIT Scheme and T there are first class environments, called locales
in T, where incremental (top level) definition is legal.  Definition
in these environments affects only them and their "children", but
affects no other first class environments.  Systems can be structured
in such a way that defining in the "user initial" environment does not
affect system code at all, but affects all the user code "loaded"
there.  Thus the user can get whatever definition of CAR s/he wants
while the system continues using whatever else it wants.

If you want to "redefine" something for the system as well, you have
to do a little more work, since you first have to find what binding
(or bindings) affect the system, and then assign it (them) to the
desired value.  Since doing this unadvertently is very unlikely, there
is no need for warnings or switches.

I find that this scenario provides a reasonable degree of system
security against unintentional damage, while providing significant
power to knowledgeable users.

Unfortunately R3RS does not provide any notion of multiple first class
environments or top levels, so it is inconvenient to write an R3RS
portable system that has the above behavior.