> On Jul 9, 2009, at 4:32 AM, Dag Sverre Seljebotn wrote: > >> Robert Bradshaw wrote: >>> On Jul 8, 2009, at 5:07 PM, Lisandro Dalcin wrote: >>> >>>> On Wed, Jul 8, 2009 at 6:07 PM, Dag Sverre >>>> Seljebotn<[email protected]> wrote: >>>>> I think you mistunderstood me... I meant (1) and (2) in >>>>> combination. >>>> >>>> Indeed... My fault this time... >>>> >>>>> Trying again: >>>>> >>>>> 1) We introduce "?" >>>>> 2) If you do not know the exact type, you HAVE to use ?. Not >>>>> using ? >>>>> implies you know the exact type. >>> >>> >>> I think this is a bad idea. If you have an extern typedef int, how >>> often do you really know what it is? On all platforms? With all c >>> configuration options and into the future? Nearly every typedef int >>> would have to be unranked, which would be a pain to code with. >> >> I just don't see what alternative you are proposing though? Today's >> behaviour is not even defined except through an ever-changing >> implementation, and leads to bugs; is that what you are proposing >> to keep? >> >> Just write down the exact behaviour that you want and I'll be able to >> follow you here. > > "ctypdef int foo" means that foo will be a signed integer type, and > most of the code involved will be size-agnostic, but when mixing with > other types it will have the ranking of an int. This is what it means > now, right? Perhaps we could say that rankings being equal, we defer > to the typedef type.
It doesn't mean that yet, but when #333 is reviewed and applied, then yes. > I just looked at the Sage codebase and there aren't nearly as many > extern ctypedef ints as I thought. Nearly all of them are not a > specific size, yet we still often do arithmetic with them (e.g. with > literal ints). Short of a configure script, there is often no way to > know at Cython compile time what the actual sizes are. > > If I understand your proposal, you want to make an "ctypedef int foo" > mean > > ctypedef int foo # as it is now > assert sizeof(int) == sizeof(foo) > > and > > ctypedef some int foo # or whatever notation we have > > mean we disallow all rank-based decisions (unless we provide explicit > rank information). Yes. 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) until somebody can invest much more time in this. 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. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
