On Nov 5, 2009, at 2:31 AM, Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> On Nov 3, 2009, at 10:15 AM, Lisandro Dalcin wrote: >> >>> On Tue, Nov 3, 2009 at 3:06 PM, Dag Sverre Seljebotn >>> <[email protected]> wrote: >>>> Lisandro Dalcin wrote: >>>> >>>>> Do you remember that I advocated for "ctypedef some int MyInt" or >>>>> something similar? If right now we had that, Cython could reject >>>>> some >>>>> things, like binops on different "ctypedef some .." types, >>>>> requiring >>>>> users to introduce casts to resolve the ambiguity... A said it >>>>> before, >>>>> and I say it again: second-guessing is a bad thing (or, in >>>>> Python's >>>>> Zen words: "In the face of ambiguity, refuse the temptation to >>>>> guess.") >>>>> >>>> I remember very well, and I've been thinking about it the whole >>>> day. I >>>> wholeheartedly agree with you that the situation is not good. >> >> I think in generally this is an unsoveable problem as the Cython >> stage >> completes before the C stage starts (and generating code for all >> possible permutations isn't feasible in general). This means also >> that >> the author of the code doesn't (necessarily) know the size of the >> external types before C compile time, and they may change from >> platform to platform. > > It's definitely unsolveable -- and yet we can seek a "better local > optimum" than what we have today (mainly because the current behaviour > feels inconsistent, and inconsistency leads to hard-to-learn and > bugs).
I agree that we can do better. >> We're still going to have to deal with this for function overloading >> (and there it's even nastier, as sizeof(a) >= sizeof(b) has different >> semantics from sizeof(a) == sizeof(b)). > > For talking with C++, the C++ compiler deals with it. > > For Cython-specific/C-only, I think we should seriously consider > disallowing overloading based on size. We simply don't allow > > cdef foo(double x) > cdef foo(float x) > > But let's cross that bridge when we come to it... Well, cdef long max(long a, long b) cdef int max(int a, int b) and cdef float sin(float) cdef double sin(double) May both come in handy, but abuse of overloading based on size could be really nasty. (I don't think this is specific to Cython, but to writing portable code in general.) >>>> Another, perhaps more "backwards-compatible" approach is >>>> (backwards-compatible in the following sense: It will break code >>>> that >>>> should be broken and fixed, and not suddenly introduce bugs that >>>> are >>>> hard to find): >>>> >>>> a) Tighten down everything so that explicit casts are needed even >>>> for >>>> stuff like this: >>>> >>>> cdef long i >>>> cdef external_typedef_int j >>>> print i / j # not allowed, must do i / <long>j >>>> >>> OK, +1 on this... >> >> I think this may be too much of a backwards incompatible change. >> Would >> one then have to do >> >> cdef external_typedef_int j >> print j / <external_typedef_int>2 >> print <long>j / 2 >> >> ? > > Hmm. But today, this would lead to a bug on 32-bit Linux: > > cdef extern from "header.h": > ctypedef short my_longlong # really long long > > cdef my_longlong f(my_longlong x): > return x // 2 > > I'm pretty sure this would result in 32-bit division rather than 64- > bit. Yes, that's true, and I could be bad (though only if you're storing values larger than shorts, in which case the extern definition is clearly wrong, though that might not always be obvious). > Long-term, as we've pretty much decided to have literals have Python > semantics (i.e. Stefan's work on folding compile-time expressions), I > think this problem can be worked around by changing the typing phase > somewhat and have literals be the widest possible type (signed or > unsigned depending on context...or something). One thing to avoid is, with type inference we don't want to make x = 3 create a long-long typed x. Perhaps they could be typed according to context somehow (if this doesn't get too complicated to reason about). >> The phrase "should be broken and fixed" is somewhat subjective. Care >> should be taken when marking something that is potentially broken as >> something that is definitely broken. >> >> At the very least we should start with a directive that emits >> warnings >> or errors to see how much stuff it breaks and how constraining it is >> to work with first. > > Very good idea. I'll direct any future efforts in this area towards > such > a feature rather than on the mailing list. Cool, thanks. And an eventual CEP. > (Not that I promise to do it, I think memoryviews are ahead of it in > my > queue.) Sure. I think memoryviews will be more valuable to have as well (though if we both had an infinite amount of time to work on things...). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
