opt-class

[Joe Gibbs Politz]

The opt-class field of functions is *only* used to handle no-arguments super() right now, right?  I'm running tests to confirm, but I want to make sure that my intuition is right.

[Alejandro Martinez]

Yes, that should be the case. The same applies to the stk parameter for interp-env.

2013/3/27 Joe Gibbs Politz <joe.p...@gmail.com>

The opt-class field of functions is *only* used to handle no-arguments super() right now, right?  I'm running tests to confirm, but I want to make sure that my intuition is right.

--
You received this message because you are subscribed to the Google Groups "lambda-py" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lambda-py+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Alejandro.

[Joe Gibbs Politz]

OK, confirmed, never consing anything onto stk causes us to fail 3 tests, all having to do with super.

I was trying to figure out how imperative it is to explain the third position on functions.  The answer is not very; it lets us handle one extremely dynamic feature.

[Alejandro Martinez]

I was playing with super() no arguments and found it is not that dynamic as I thought, the tests are in this commit and my provisional conclusions are:

1) super() no arguments only works in functions nested inside methods provided the function receives "self" as the first argument.

2) super() doesn't work in functions external to methods even when "self" is passed as first argument.

Based on this I think we can get rid of the opt-class/stk stuff implementing super() no arguments this way:

- Function prelude: each function has a prelude to assign the first parameter to a local hidden variable $self and, if it is inside a class, assign the statically determined class to $class

- self.__init__: in the no arguments case it uses $self and $class, raising the corresponding error if any of them is not defined ($self will be undefined or be None in 1) and $class will be undefined or None in 2) above), furthermore it does the same isinstance/issubclass check as super(cls, obj).

[Alejandro Martinez]

Correction; last paragraph should be:

- super.__init__: in the no arguments case it uses $self and $class from the callers locals()***, raising the corresponding error if any of them is not defined ($self will be undefined or be None in 1) and $class will be undefined or None in 2) above), furthermore it does the same isinstance/issubclass check as super(cls, obj).

The *** is the key, in my own implementation I used a full dynamic scope lookup for this but, it the light of the tests shown, it seems to be overkill, it should be sufficient to look in the locals(). Although this is not that simple because this is not a simple function call...

2013/3/29 Alejandro Martinez <amtri...@gmail.com>

--
Alejandro.

[Joe Gibbs Politz]

(Delayed response from me; I took a few days off after the paper).

This is a really useful simplification, thanks for getting those tests together.  Since it does seem like super() can be done in terms of locals(), I wonder what the smallest set of "context" we need to store at the top of functions in desugaring is.  Right now, it seems like just:

- $self and $class

- locals()

One useful question to ask is which dynamic features exist that would make us extend this set of information in the context?  Just describing what information each function needs to keep track of is useful.  I wonder if there's a simple listing in a C struct in the CPython implementation somewhere, and if we're reverse-engineering that?