[plt-scheme] An Editors Tale

On Wednesday, February 4, 2004, at 01:16 AM, Jeremy Hylton wrote:

> 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
>
> Do you?  (I'm late getting back to this thread, but I wanted to add a
> few things.)

Perhaps you misunderstood my question. People have been looking
for such analyses for a long time, including the stream of people out
of plt who worked on soft typing. It's a game with huge odds against
you.

> Do you know of any analysis that deals with higher-order objects and
> MOPs?  I think Python's metaprogramming facilities are evolving slowly,
> and I, for one, don't have any experience with Common Lisp MOPs.
>
> 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.
>
> I think the only problematic methods are __getattr__ and company.  I
> think they tend to be over-used in Python programs; most code that uses
> a __getattr__ hook would probably be better off doing something less
> dynamic.  (I probably disagree with ESR on this point.)  On the other
> hand, it's incredibly valuable in a few rare cases.  The persistence
> system I talked about at LL2 depends on being able to trap attribute
> accesses to persistent objects.
>
> A slightly different tack would be to ask what benefits Python
> programmers would get if they avoided the dynamic features that cause
> problems.  If there's some static analysis that only works on a subset
> of Python code and that analysis is valuable, then there's incentive 
> for
> programmers to use only that subset of Python.


Programmers would be able to debug their programs statically,
meaning find bugs without running them and stumbling across
those test cases that trigger a strange mistake. Compilers would
work then (optionally) and probably give you an order of magnitude
or so.

> I also don't know how to take your comment that Python isn't OO, it's
> just got dictionaries.  It sounds a little like saying C++ isn't OO,
> it's just got vtables.  The runtime representation is dictionaries
> (mostly), but they don't capture any of the rules for inheritance,
> method resolution, etc.  Those rules are the core of the object system.
> (And they are open to extension using metaclasses.)

C++ isn't OO because classes don't enforce abstraction boundaries
that should come with "class".

Python isn't OO because the classes and objects aren't opaque
abstract things. (Normally one uses the word 'object' here in the
sense of philosophy. But OO people stole it, abused it, repossessed
the word ... so I have to use this strange English word 'thing' 
instead).

-- Matthias