On 9 May 2012 09:28, mark florisson <markflorisso...@gmail.com> wrote:
> On 9 May 2012 09:02, Vitja Makarov <vitja.maka...@gmail.com> wrote:
>> 2012/5/9 Stefan Behnel <stefan...@behnel.de>:
>>> Robert Bradshaw, 09.05.2012 00:12:
>>>> On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote:
>>>>> 2012/5/8 Stefan Behnel:
>>>>>> Vitja has rebased the type inference on the control flow, so I wonder if
>>>>>> this will enable us to properly infer this:
>>>>>>
>>>>>> def partial_validity():
>>>>>> """
>>>>>> >>> partial_validity()
>>>>>> ('Python object', 'double', 'str object')
>>>>>> """
>>>>>> a = 1.0
>>>>>> b = a + 2 # definitely double
>>>>>> a = 'test'
>>>>>> c = a + 'toast' # definitely str
>>>>>> return typeof(a), typeof(b), typeof(c)
>>>>>>
>>>>>> I think, what is mainly needed for this is that a NameNode with an
>>>>>> undeclared type should not report its own entry as dependency but that of
>>>>>> its own cf_assignments. Would this work?
>>>>>>
>>>>>> (Haven't got the time to try it out right now, so I'm dumping it here.)
>>>>>>
>>>>>
>>>>> Yeah, that might work. The other way to go is to split entries:
>>>>>
>>>>> def partial_validity():
>>>>> """
>>>>> >>> partial_validity()
>>>>> ('str object', 'double', 'str object')
>>>>> """
>>>>> a_1 = 1.0
>>>>> b = a_1 + 2 # definitely double
>>>>> a_2 = 'test'
>>>>> c = a_2 + 'toast' # definitely str
>>>>> return typeof(a_2), typeof(b), typeof(c)
>>>>>
>>>>> And this should work better because it allows to infer a_1 as a double
>>>>> and a_2 as a string.
>>>>
>>>> This already works, right?
>>>
>>> It would work if it was implemented. *wink*
>>>
>>>
>>>> I agree it's nicer in general to split
>>>> things up, but not being able to optimize a loop variable because it
>>>> was used earlier or later in a different context is a disadvantage of
>>>> the current system.
>>>
>>> Absolutely. I was considering entry splitting more of a "soon, maybe not
>>> now" type of thing because it isn't entire clear to me what needs to be
>>> done. It may not even be all that hard to implement, but I think it's more
>>> than just a local change in the scope implementation because the current
>>> lookup_here() doesn't know what node is asking.
>>>
>>
>> That could be done the following way:
>> - Before running type inference find independent assignment groups
>> and split entries
>> - Run type infrerence
>> - Join entries of the same type or of PyObject base type
>> - Then change names to private ones "{old_name}.{index}"
>
> Sounds like a good approach. Do you think it would be useful if a
> variable can be type inferred at some point, but at no other point in
> the function, to specialize for both the first type you find and
> object? i.e.
>
> i = 0
> while something:
> use i
> i = something_not_inferred()
>
> and specialize on 'i' being an int? Bonus points maybe :)
>
> If these entries are different depending on control flow, it's
> basically a form of ssa, which is cool.
You could reuse entry cnames if you re-encounter the same type though,
but it would be nice if they were different, uniquely referencable
objects if they originate from different assignment or merge points.
> Then optimizations like
> none-checking, boundschecking, wraparound etc can, for each new
> variable insert a single check (for bounds checking it depends on the
> entire expression, but...). The only thing I'm not entirely sure about
> is this when the user eliminates your check through try/finally or
> try/except, e.g.
>
> try:
> buf[i]
> except IndexError:
> print "no worries"
>
> buf[i]
>
> Here you basically want a new (virtual) reference of "i". Maybe that
> could just be handled in the optimization transform though, where it
> invalidates the previous check (especially since there is no
> assignment here).
>
>> --
>> vitja.
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel@python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
