[Cython] #303 + simplifying type system

[Lisandro Dalcin]

On Thu, May 14, 2009 at 4:08 PM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> Robert Bradshaw wrote:
>>
>> Does this have a performance impact compared to the other way? It
>> does bloat the code some. (Maybe it's not critical anyways.)
>

Give me a bit more of time to give a definitive comment on this, but ...

> Well, it is only used for external typedefs, and considering that the
> bug is quite critical (basically it's very easy to do *(long
> long*)&some_short)...
>
> Haven't benchmarked it, we could consider switching to my original
> proposal later..
>

... as long as the "property" is defined with a C protocol (instead of
the Python-side "property" builtin), I do not expect a impact on
performance.

>
>Lisandro, would you like to argue why you were -1?
>

For the same rationale that othes gave on this thread (basically, the
impact on C semantics), and because I believe a better and backward
compatible solution can be found.

Simplifying  the whole type system seems a mistake to me, in the
temptation to guess, I would just guess ONLY in the case of external
ctypedef's. Moreover, we could extend this to make "ctypedef signed
value" as an unknown-size integral, but if the code does "ctypedef int
value", assume that the ctypedef is actually a "int" and treat it like
that. Of course, we have a problem with floating poing. Then perhaps,
you should enable a special declarations for integrals and floatings
like this:

ctypedef signed integral i
ctypedef unsigned integral j
ctypedef floating x # or "floatingpoint", or "inexact"

and ONLY in such case we treat such declarations as unknown-size types.

Does this make sense?

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594