Previous related mail is in:
http://www.ccs.neu.edu/research/demeter/pub-impls/under-dev/python

Hi Doug:

I think I forgot to put your AP/STklos system on the Web.
Please can you tell me where it is.

In Demeter/Flavors (10 years ago) we followed Johan's approach 1.

I think that it would also make sense to have a dynamically 
changing class graph together with TAO while using general
traversal strategies. I think positive constraints are more
natural.

Johan, we need to refer to a document which describes TAO.
What is the URL?

-- Karl

>From dougo@ccs.neu.edu Sat May  9 15:13:04 1998
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Johan Ovlinger <johan@ccs.neu.edu>
>Cc: dem@ccs.neu.edu, veitc@sovereign.org
>Subject: Re: Porting demeter to python
>
>Johan Ovlinger writes:
> > The main problem I forsee is that we'll have to change the semantics
> > of either python or travesals. Traversals currently are typed, they
> > only make sense it interpreted in the context of a static class
> > graph. However, python is very untyped, and thus has no concept of
> > static class graphs. 
> > 1) We could just say that if you want to use traversals, you had better
> >    not break our assumptions about the classgraph. Hrm. 
> > 2) By only using bypassing constraints in traversals, we could retain
> >    the semantics of traversals w/o needing to know the class graph. 
> > 
> > I prefer 2. This means that the system needs NO compile time support,
> > which is all in the spirit of python. 
>
>I think CLOS has the same problem (class members are untyped) so it
>would be worthwhile to look at how that implementation works.  My
>AP/STklos system used strategy 2, i.e. traversals were essentially "go
>everywhere but bypass this list of classes and edges", which meant you
>had to do a lot of hand-pruning.  Still, it worked out okay (I
>implemented an optimizing compiler using it).
>
>--Doug
>