[plt-scheme] An Editors Tale

> On Thu, 2004-01-29 at 13:36, Matthias Felleisen wrote:
>> Ah, but the problem is that 3% "black holes" that you inject into a 
>> program analysis quickly pollute the entire analysis. Do you know of an 
>> analysis that copes with higher-order objects (closures) and "black 
>> holes" (without additional information about them)? -- Matthias
>

Jeremy Hylton <jeremy at alum.mit.edu> writes:

> Ken's list of methods with __names__ covers operator overloading and
> metaprogramming.  Methods like __getitem__ and __cmp__ are just there to
> support overloading for indexing and comparison, respectively.  I assume
> they don't pose an issue for analysis.

It depends.  In a language like Scheme, a vector is an object that you
can index.  The semantics of indexing into a vector are well-defined,
and narrow.  For example, fetching the contents of a vector can never
side effect.  A fetch from a vector can be transposed with another
operation if you can prove the other operation does not side-effect
*that particular* vector.

Now if you are willing to *guarantee* that no use of __getitem__
anywhere will violate the standard semantics of indexing, then you can
pretty much ignore it.  Some operators, like __names__, have trivial
semantics and such obvious intent that it seems rather pointless to
code defensively in case someone redefined __names__ to cause side
effects to irrelevant structures.  But other operators are
specifically *designed* to be hooked on to in arbitrary ways and these
are the ones that cause problems.