Re: Question with binding

[titan!dorai@rice.edu (Dorai Sitaram)]

In article <8904191633.AA14869@sesame.Stanford.EDU> mkatz@sesame (Morris Katz) writes:
$   Date: Tue, 18 Apr 89 01:07 EDT
$   From: Andre van Meulebrouck <vanMeule@ALLEGHENY.SCRC.Symbolics.COM>
$       Date: 17 Apr 89 20:36:41 GMT
$       From: titan!dorai@rice.edu  (Dorai Sitaram)
$       [...]
$       A bunch of primitive functions, e.g., +, cons, etc., were treated as
$       _constants_ in the sense that the names could not have other values
$       assigned to them.  [...]
$
$   ^^That's my understanding too:  the idea that certain procedures can't change
$   during the course of a compilation/computation, otherwise things couldn't be
$   guaranteed to make sense if they were meanwhile allowed to change underneath
$   your feet during the computation/compilation.  As to user defined
$   functions--well if you want to do those sorts of things with your own functions,
$   okay, but the system won't let you do that with its functions (upon which it
$   might depend, or otherwise feels some responsibility to protect the integrity
$   of). [...]
$
$   In MacScheme, if you try (define + ...) you get:
$
$   ERROR:  Integrable procedures may not be redefined.  
$   (set! + ...)
$
$   I like the idea of that a great deal...I don't think the convenience of being
$   able to redefine things (advertently or inadvertently--with or without warning)
$   is a wonderful feature.  You can always write your own similar functions with
$   different names, and call out to those in preference if a system function isn't
$   quite what you wanted, right?
$
$       --dorai
	^^^^^^^
Not right (for me). BTW, I did _not_ say the above. They are Andre's
words. I needed to say this, because I tend to the diametrically
opposite opinion >:-].

$Yes, but this may not be the correct way to think about things.  Lets say that
$I want to count the number of cons cells that are formed in a suite of
$programs.  A good way to do this might be to create an environment in which the
$constructors like CONS and LIST were aliased to versions that counted the
$number of cells they allocated.  The program suite could then be run in this
$new environment to gather the desired statistics.  I would find the alternative
$of modifying all of the programs in the test suite much less elegant and quite
$inconvenient.  In on approach the cost of implementation is constant and in the
$other it is proportional to the size of the test suite.
$					Morry Katz

An earlier version of Chez did in fact allow redefinition of system
"constants" to be visible in existing system code, not just in
existing (and of course future) user code. One can use this to good
effect to define modified versions of the interpreter-eval, Morry's
cell-counting cons, etc. However, the current Chez has a most curious
stance on this matter. System "constants" can be redefined, but while
existing user code reflects these changes, system code is immune.
Obviously, there is no inlining going on. It's almost as if the
implementors took care to seal off system code with a huge "let",
i.e., (let ([cons cons] ... [<sys-const> <sys-const>] ...)
<sys-code>), so that any redefinition of the <sys-const>'s doesn't
affect <sys-code>.

I agree with Andre that redefinition of system-defined functions could
infringe upon the integrity of the system. In the old Chez, one needed
to just type (set! cons 0) to have the whole session come tumbling
down like a house of cards. But then, I don't think the guy who said
"Eternal vigilance is the price of liberty" meant it as an argument
_against_ liberty.

--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice.       --Isaac Bashevis Singer
------------------------------------------------------------------------------