[Cython] Fused Types
stefan_ml at behnel.de
Fri Apr 29 04:09:56 CEST 2011
mark florisson, 28.04.2011 23:29:
> On 28 April 2011 22:31, mark florisson wrote:
>> On 28 April 2011 22:12, Robert Bradshaw wrote:
>>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson wrote:
>>>> So I fixed all that, but I'm currently wondering about the proposed
>>>> cython.typeof(). I believe it currently returns a string with the type
>>>> name, and not the type itself.
>>> Yes. This is just because there's not really anything better to return
>>> at this point. We should "fix" this at some point in the future.
>>>> So I think it would be inconsistent to
>>>> suddenly start allowing comparison with 'is' and 'isinstance' and
>>> I'm open to other suggestions, but would like an expression that
>>> resolves at compile time to true/false (and we need to do branch
>>> pruning on it). Note that type() is not good enough, because it has
>>> different semantics, i.e.
>>> cdef object o = 
>>> typeof(o), type(o)
>>> so lets not touch that one.
>> Right, so for fused types I don't mind string comparison with
>> cython.typeof(), but retrieval of the actual type for casts and
>> declaration remains open. I'd be fine with something like
> It seems that this isn't optimized yet, but it looks to me like it
> wouldn't be very hard to do so. At least == and != could be resolved
> at compile time if the other operand is a string literal.
Well, the obvious place where this would happen for free would be constant
folding. But that runs *way* before type analysis, so all it sees is the
typeof() call, not the string.
Optimising this would thus basically require a second (simpler?) constant
folding step, or at least an additional hook during (or after) type
analysis that does the comparison. I wouldn't mind too much, given that
type analysis can end up injecting some rather handy information into the
tree. So a second (even complete) constant folding step *after* type
analysis may still introduce some nice optimisations.
We may actually consider splitting constant folding into two steps - one
that calculates the results as early as possible (and maybe does only
safe&obvious tree replacements, e.g. boolean values, strings, etc.) and a
second step that replaces subtrees by constant nodes once it knows the
final type of the result.
More information about the cython-devel