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