arigo at tunes.org
Mon Jun 16 17:27:48 CEST 2003
On Sun, Jun 15, 2003 at 07:19:19AM +0200, Günter Jantzen wrote:
> Typically, however, abstract object spaces are a (little) bit less abstract,
> still maintaining a minimal amount of information about the objects. For
> example, a wrapped object could be represented by its type. You then define
> the object space's add to return int when the two arguments are int and int.
> This concept will only work when output types can be determined by input
> types (independent of concrete values).
Yes, the example was a bit rough. One way to make it more complete is by
giving the following precision: by "type" I did not necessarily mean a type
object in Python's sense. It could be any kind of subset on the set of all
Python objects. Thus in your example:
> def spamrelease(i):
> if i > 0:
> return i - 1
> return "counter is closed"
the return value can be determined to be of a type that is the union of
Python's int and str types. (If you work slightly harder you can determine
that it must be of type "either an integer in range(0, sys.maxint) or the
constant "counter is closed".)
> Consequently we should work with function prototypes. Not as restrictive as
> in C. More a set of rules or patterns for calculating output types from input types.
I had in mind a variable-oriented type inference (using disjunctions in their
types), not a function-oriented one that would analyse several versions of
them, even if the latter might be more precise. But then any would be
possible. It's just that at this point I think that our translator should not
need to emit several versions of the same function for different argument
More information about the Pypy-dev