Hello everybody, I've been progressing on putting the pieces together and will check-in my changes as soon as possible. The stdobjspace is getting ready to be tested together with the interpreter, but is not quite there yet. If someone (Michael?) can figure out a good solution for the END_FINALLY problem, I'd love to hear it. The problem is that in a try:except: block, when we enter the except: part, there are some control paths that reach the final END_FINALLY opcode (re-raising the exception) and some that don't (caught exception). It makes it hard to know when we must remove from the blockstack the description of the potentially re-raisable exception. I was also thinking about the explicit multimethod registration in the standard object space. For example, intobject.py contains the following code: def int_int_add(space, w_int1, w_int2): ... StdObjSpace.add.register(int_int_add, W_IntObject, W_IntObject) def int_int_sub(space, w_int1, w_int2): ... StdObjSpace.sub.register(int_int_sub, W_IntObject, W_IntObject) def int_int_mul(space, w_int1, w_int2): ... StdObjSpace.mul.register(int_int_mul, W_IntObject, W_IntObject) I am proposing that it could be written with some more declarative idiom abusing the 'class' keyword, something along these lines: class __multi__(W_IntObject, W_IntObject): def add(w_int1, w_int2, space): ... def sub(w_int1, w_int2, space): ... def mul(w_int1, w_int2, space): ... It looks much nicer, I think, and it addresses a point raised during the sprint (by Stephan if I remember right) about making the xxxobject.py files less dependent on the actual name of their object space. Indeed, the 'class __multi__' code no longer mentions StdObjSpace. This can be implemented using an original dispatching algorithm that has been as far as I know invented for the Slate language (http://slate.tunes.org/). The implementation of 'class __multi__(X, Y)' is defined to store the function objects defined in the body -- here add(), sub(), mul() -- into *both* the X and the Y class, into special-named attributes. Performing dispatch to 'space.add(x,y)' is done by looking into the class of 'x' and the class of 'y' to see if we can find the same function object in both. More specifically, after a definition like class __multi__(X, Y): def f(x, y, extra): ... we would have the function object 'f()' stored into each of the lists 'X.__dispatch_on_arg_1__' and 'Y.__dispatch_on_arg_2__'. Then a call like 'f(x,y,extra)' looks up the types of 'x' and 'y' and searches for a function object that would be present both in 'x.__class__.__dispatch_on_arg_1__' and 'y.__class__.__dispatch_on_arg_2__'. What is nice with this approach is the removal of the need for a central "repository" of functions, role which was currently held by StdObjSpace.add. BTW the new order of the arguments ('space' at the end) is such that single-dispatch is a particular case of Python's original dispatch semantics, with the argument we dispatch on being first (althought that original semantic is also extended by the delegation stuff, e.g. delegating from 'int' to 'long' for methods that fail to be implemented by 'int' for overflow reasons). A bientôt, Armin.
Armin Rigo wrote: ...
Hmm, "deriving" from the same class twice doesn't look very clean, and space at the end, and no "self", hmm hmm.
I agree that this is an advantage. ...
Well, I see that class __multi__ should have a special meta-class, in order to behave as you like? Or is it just a placeholder, interpreted by something else?
I don't get why spae at the end is an advantage? Just for not pretending to be something like "self"? Please give me an example how I would change my intobject implementation. Do you mean that instead of the single functions, I should put together such a __multi__ class? The current way of doing things was not so bad, since we had a defined interface which operations exist. How should it be done without StdObjSpace.add.register(int_int_add, W_IntObject, W_IntObject) Also, how about sticking with one agreed interface for, say, at least two weeks and have more objects implemented? I'm not happy to change tested code all over again. At least, with the current frequency of design changes, I'm a bit reluctant to do anything on IntObject. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Armin Rigo <arigo@tunes.org> writes:
Is this the problem that we sometimes push interpreter level objects onto the applications's stack? I'm not sure we have much freedom here unless we fiddle the compiled bytecodes. But I'm still a little fuzzy on the issues. Cheers, M. -- Unfortunately, nigh the whole world is now duped into thinking that silly fill-in forms on web pages is the way to do user interfaces. -- Erik Naggum, comp.lang.lisp
Michael Hudson wrote: ...
Oh, do we do that? The CPython equivalent would be to push plain integers, mixed with real object addresses :-) I think we should better not do this, 'cause these two worlds are meant to be absolutely incompatible without wrappers. It might make sense if I extend the set of restricted objects so we can use them for the interpreter. For example, I could write a derived list type, which is only able to hold either wrapped objects, or None, which would act line NULL in C. Such restricted objects would also make it very clear to a compiler, what code to create. cheers - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer <tismer@tismer.com> writes:
At the moment, yes. Well, occasionally.
Yes! It's a bug. But neither Armin nor myself have found the brain cells to sort this one out yet. Cheers, M. -- If comp.lang.lisp *is* what vendors are relying on to make or break Lisp sales, that's more likely the problem than is the effect of any one of us on such a flimsy marketing strategy... -- Kent M Pitman, comp.lang.lisp
Michael Hudson wrote:
...
Yes! It's a bug. But neither Armin nor myself have found the brain cells to sort this one out yet.
Hey, this is then a very good reason to implement a restricted array object. You just plug it into the frame as its stack, and it will crash when it feels abused. :-) ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
I don't know if this is in line with Christians comment, but I'd like to make a kind of proposal. Until now, I'm very uncomfortable with the way we are implementing the stdobjspace. I have the feeling (there it is, this kind of discussion shouldn't be based on "feelings") that our implementation is somewhat circular, since we are using real Python objects to base our implementation of PyPython objects on. I'd rather have the notion of an external library our internal building blocks are coming from. To make it more clear what I mean, I'll describe, what I have in mind with "numbers". During the last few days, there was (is) an discussion on c.l.p about float arithmetic and some problems, one can run into. In that discussion, the following paper was mentioned: http://www2.hursley.ibm.com/decimal/decarith.html It describes a number implementation that is compatible with "floats" and "ints". To make it short, a number is a triple (sign,coefficient,exponent) whereas the exponent is a base 10 exponent. 0.25 thus could be written as (+,25,-2) The paper goes on in describing all the operations, exceptions, etc. that are needed to implement a number library based on that number model. The way, Python numbers are implemented at the moment, is to take the low level C "numbers" and wrap them as good as it gets and add a lot of code where things are missing. I'd rather take a usefull number implementation and just wrap that (and translate only the exceptions, errors). In order to implement such a number scheme, we'd need of course some notion of bit fields. This boils down to: 1. define the most basic building blocks like bit fields + corresponding memory management. 2. define numbers, lists, strings, dicts, etc. on top of 1. Please note that these objects have nothing to do with the objspace we are defining, but are used as the building blocks and are never exposed outside the objspace. Does this make sense? Cheers Stephan
Hello Michael, On Tue, Feb 25, 2003 at 02:04:51PM +0000, Michael Hudson wrote:
I think I came up with a reasonable solution. If you read the Python docs on sys.exc_info() (http://www.python.org/doc/current/lib/module-sys.html#l2h-246) you see a description that makes natural the introduction of a new stack, the "exception stack", of which sys.exc_info() would return the top-most item. Then I think that we can use this execution-context-global (not frame-dependent) stack to store the current exceptions. The END_FINALLY opcode can work by inspecting this stack to know if there is an exception to restore or not. It is also cleaner than both CPython, which abuses the valuestack to store the exception stuff, and the current pypy, were we abuse the blockstack for this purpose. A bientôt, Armin.
Armin Rigo wrote: ...
Hmm, "deriving" from the same class twice doesn't look very clean, and space at the end, and no "self", hmm hmm.
I agree that this is an advantage. ...
Well, I see that class __multi__ should have a special meta-class, in order to behave as you like? Or is it just a placeholder, interpreted by something else?
I don't get why spae at the end is an advantage? Just for not pretending to be something like "self"? Please give me an example how I would change my intobject implementation. Do you mean that instead of the single functions, I should put together such a __multi__ class? The current way of doing things was not so bad, since we had a defined interface which operations exist. How should it be done without StdObjSpace.add.register(int_int_add, W_IntObject, W_IntObject) Also, how about sticking with one agreed interface for, say, at least two weeks and have more objects implemented? I'm not happy to change tested code all over again. At least, with the current frequency of design changes, I'm a bit reluctant to do anything on IntObject. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Armin Rigo <arigo@tunes.org> writes:
Is this the problem that we sometimes push interpreter level objects onto the applications's stack? I'm not sure we have much freedom here unless we fiddle the compiled bytecodes. But I'm still a little fuzzy on the issues. Cheers, M. -- Unfortunately, nigh the whole world is now duped into thinking that silly fill-in forms on web pages is the way to do user interfaces. -- Erik Naggum, comp.lang.lisp
Michael Hudson wrote: ...
Oh, do we do that? The CPython equivalent would be to push plain integers, mixed with real object addresses :-) I think we should better not do this, 'cause these two worlds are meant to be absolutely incompatible without wrappers. It might make sense if I extend the set of restricted objects so we can use them for the interpreter. For example, I could write a derived list type, which is only able to hold either wrapped objects, or None, which would act line NULL in C. Such restricted objects would also make it very clear to a compiler, what code to create. cheers - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer <tismer@tismer.com> writes:
At the moment, yes. Well, occasionally.
Yes! It's a bug. But neither Armin nor myself have found the brain cells to sort this one out yet. Cheers, M. -- If comp.lang.lisp *is* what vendors are relying on to make or break Lisp sales, that's more likely the problem than is the effect of any one of us on such a flimsy marketing strategy... -- Kent M Pitman, comp.lang.lisp
Michael Hudson wrote:
...
Yes! It's a bug. But neither Armin nor myself have found the brain cells to sort this one out yet.
Hey, this is then a very good reason to implement a restricted array object. You just plug it into the frame as its stack, and it will crash when it feels abused. :-) ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
I don't know if this is in line with Christians comment, but I'd like to make a kind of proposal. Until now, I'm very uncomfortable with the way we are implementing the stdobjspace. I have the feeling (there it is, this kind of discussion shouldn't be based on "feelings") that our implementation is somewhat circular, since we are using real Python objects to base our implementation of PyPython objects on. I'd rather have the notion of an external library our internal building blocks are coming from. To make it more clear what I mean, I'll describe, what I have in mind with "numbers". During the last few days, there was (is) an discussion on c.l.p about float arithmetic and some problems, one can run into. In that discussion, the following paper was mentioned: http://www2.hursley.ibm.com/decimal/decarith.html It describes a number implementation that is compatible with "floats" and "ints". To make it short, a number is a triple (sign,coefficient,exponent) whereas the exponent is a base 10 exponent. 0.25 thus could be written as (+,25,-2) The paper goes on in describing all the operations, exceptions, etc. that are needed to implement a number library based on that number model. The way, Python numbers are implemented at the moment, is to take the low level C "numbers" and wrap them as good as it gets and add a lot of code where things are missing. I'd rather take a usefull number implementation and just wrap that (and translate only the exceptions, errors). In order to implement such a number scheme, we'd need of course some notion of bit fields. This boils down to: 1. define the most basic building blocks like bit fields + corresponding memory management. 2. define numbers, lists, strings, dicts, etc. on top of 1. Please note that these objects have nothing to do with the objspace we are defining, but are used as the building blocks and are never exposed outside the objspace. Does this make sense? Cheers Stephan
Hello Michael, On Tue, Feb 25, 2003 at 02:04:51PM +0000, Michael Hudson wrote:
I think I came up with a reasonable solution. If you read the Python docs on sys.exc_info() (http://www.python.org/doc/current/lib/module-sys.html#l2h-246) you see a description that makes natural the introduction of a new stack, the "exception stack", of which sys.exc_info() would return the top-most item. Then I think that we can use this execution-context-global (not frame-dependent) stack to store the current exceptions. The END_FINALLY opcode can work by inspecting this stack to know if there is an exception to restore or not. It is also cleaner than both CPython, which abuses the valuestack to store the exception stuff, and the current pypy, were we abuse the blockstack for this purpose. A bientôt, Armin.
participants (4)
-
Armin Rigo -
Christian Tismer -
Michael Hudson -
Stephan Diehl