[pypy-dev] Re: Base Object library (was: stdobjspace status)

[Laura Creighton]

In a message of Thu, 27 Feb 2003 17:23:44 +0100, Stephan Diehl writes:
>On Thursday 27 February 2003 16:53, you wrote:
>> Hello Stephan, hello Laura,
>>
>> Thanks Laura for pointing out the potential language problems.
>
>Is there a possibility that Lauras mail didn't end up on the list? I coul
>dn't 
>find it.

Yes.  I wrote this, but only sent it to Armin because I thought it was
too long and maybe it was wrong too.  It is Still too long.  Apologies.

Laura

Is it possible that this misunderstanding is all about naming?  I am
getting the impression that Stephan and Christian are looking for some
basic fundamental types, the foundation of the system, to build things
out of.  And Armin is saying that there aren't any types, just
behaviours of object spaces.  This is strongly reminding me of what
happened to the physicists when they started looking for 'the
elementary building blocks of matter'.  Once you get to sub-atomic
particles, you end up with a mess to think about.  When Dirac
discovered the positron, and anti-matter, suddenly you could no longer
think of things as being made out of smaller things any more.  A
hydrogen atom is usually a proton and an electron.  But it might
temporarily be 1 proton, 2 electrons, and one positron.  This made all
the physicists go -eep-.  What's Hydrogen?  Something that behaves
like Hydrogen, it seems :-).  Time passes, and quantum dynamics is
created/discovered.  But the deep problem remains.  Werner Heisenberg
calls this the 'problem of physical content vs mathematical form'.
He said that the problem is embedded in the language we use to think.


Maybe we have a language problem too.  We shouldn't have called it the
StdObjSpace.  Instead we should have called it the
C_like_familiar_ObjSpace.  It represents one way to implement an
Object Space, and it has the desirable property that it is like the
one we know.  But we could eventually make as many of these as we like
(though only a few of them are a good idea now, or we will confuse
everybody even more than we are confusing ourselves now.)  But I am
now thiking of an ObjectSpace as, not a thing, but a collection of
behaviours.  And you can specify the behaviours.  In particular, we
can specify what behaviour is required in an Compliant Object Space,
where Compliant is now defined as 'runs C python code and gets the
same result as C python'. All of the spaces that do this will be equal
to each other in some sense, though some will be more useful, and fun
than others.  We could make 2 that are exactly the same except for,
for instance, the list implementation, which is one way to test that
we have our ideas ok.  Or one that does integers the way that we are
used to, and one that does them this new way that Stephan proposes.
Then, we can call the set of all Object Spaces that are Compliant, the
StdObjSpaces.( <-- see the s) . But the idea is not to make too many of
them, because what we need is a proof of concept that our idea of
breaking out the object spaces into their own idea, and dispatching on
that works, not the best StdObjSpace implementation.  The best one
will be determined by things like 'can Armin and Christian make it go
_really fast_, which is something we aren't supposed to be thinking
about now.  (Though its hard not to sometimes. :-) )

(We can then make non-compliant objectspaces if we like.  I mustn't think
about that either :-).

Thus what we need are experimental specifications, in the form of
unit tests, to measure whether a given objectspace is 'standard' or
not -- in other words, does it comply with C Python.  We aren't looking
for better bits to build our space out of, we are looking for better
ways to know if our space produces the correct behaviours.

Laura