On Jul 10, 2009, at 2:42 AM, Dag Sverre Seljebotn wrote:
> OK. I suppose this thread should be nearing termination; since
> this is a
> messy topic and no resolution seems at hand, I suppose the default
> is to
> keep status quo (but apply #333)
Yep. I've been meaning to look at that.
> until somebody can invest much more time in this.
I think it would be worth adding unranked types ("ctypedef some int
foo" or "ctypedef unknown int foo"), and possibly even a way to
declare relative rankings (though I don't know that we've come across
the right syntax to do this yet). Once they're in and we start using
them, then we can re-open the debate about what the default should
be. At this point we'll have a better migration path and a better
feel how restrictive (or not) using these "unranked" types actually is.
> I'll just state my reponse:
>
> a) I agree with you that most external typedefs are in reality
> unknown.
>
> b) I agree with Greg and Lisandro that when somebody write
> "ctypedef int
> foo" it is rather unobvious that Cython doesn's assume it is exact.
> (Documentation isn't always the best solution for unintuitive syntax!)
>
> c) On one hand you say the type is usually unknown, on the other
> that it
> is better to pretend that the rank is known and live with any
> disrepancies
> and errors this may cause. If the type isn't known, isn't it better
> to get
> an error and require a cast in situations where the type MUST be
> known?
> You are saying it is better to generate incorrect code...
>
> d) A simple "a = b + 34" (with different C external typedef types
> for a
> and b) is not a problem because Cython doesn't need to do anything
> with
> the rank information. Leaving the rank undefined is OK in a lot of
> situations.
>
> e) I believe one can modify Cython to rely on common sub-expression
> elimination in the C compiler instead of temporaries in some
> situations to
> eliminate most rank-based decisions and leave most to the C compiler.
>
> But, we can never get around cases like this (with C++-style
> overloading):
>
> int func(short)
> float func(long)
>
> because func can have side-effects and we can't know the type of a
> temporary to put it in.
>
> I must also note that the contrived example above leads to serious
> problems for your approach as well.
Yes, this is an inherent restriction of having the Cython compile
stage absolutely proceed the C compilation stage.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
