[Cython] CF based type inference
markflorisson88 at gmail.com
Wed May 9 17:20:03 CEST 2012
On 9 May 2012 16:13, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Dag Sverre Seljebotn, 08.05.2012 18:52:
>> Vitja Makarov wrote:
>>> 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.
>> +1 (as also Mark has hinted several times). I also happen to like that
>> typeof returns str rather than object... I don't think type inferred code
>> has to restrict itself to what you could dousing *only* declarations.
>> To go out on a hyperbole: Reinventing compiler theory to make things
>> fit better with our current tree and the Pyrex legacy isn't sustainable
>> forever, at some point we should do things the standard way and
>> refactor some code if necesarry.
> That's how these things work, though. It's basically register allocation
> and variable renaming mapped to a code translator (rather than a compiler
> that emits assembly or byte code).
> cython-devel mailing list
> cython-devel at python.org
That's not what he was hinting at though. Many of these things we're
doing are standard in compiler theory, and inventing our own ad-hoc
ways and sloppy algorithms for things like control flow, type
inference, variable renaming, bounds check optimizations, none
checking optimizations, etc, isn't going to cut it. As we have already
seen, standard ways to do control flow have worked out very great due
to Vitja's work.
More information about the cython-devel