Robert Bradshaw wrote: > On Jun 18, 2009, at 9:36 PM, Stefan Behnel wrote: >> Having the same syntax >> for memory views and SIMD views sounds like an awful lot of things >> and a very unnecessary addition, since the same can be achieved using >> the normal type instantiation syntax and type specialisation on the >> SIMD/memory-view *type* (note the difference to using that syntax on >> just *any* type). The [] syntax makes a lot of sense for the new >> array type, it makes mostly sense for buffers, it was accepted >> (IIRC) for type specialisation. IMHO, that's a long enough distance >> that we go down that road. Going further would make the language >> less parseable to humans. > > IIRC part of the motivation for int[:,:] syntax rather than > special_name[int, ndim=2] was that the former is actually easier for > humans to parse. Personally, it seems a natural extension of the int > [50] syntax.
It behaves very different, though. For one, it's not a memory allocated data object but a *view* on such a thing, just like the typed memory view. What syntax would you propose for the memory view, and if none, why not? > It also makes it very clear to me that this is not some > ordinary type implemented in some library, but a builtin type (like > int[50]) that the compiler implements internally. That's an implementation detail, not a language 'feature'. > This new type isn't > really an object, it's a multi-dimensional set of ints, the same way > int[10] or int* is a one-dimensional set of ints. No, that would be the array type, which has no SIMD behaviour. > Note that just implementing an extension class Foo, and using the > buffer syntax on Foo is insufficient (subtypes (which may override > Foo's behavior) are disallowed, Fine, trying to do so is a compile time error then. Give it a good error message saying you're "sorry but performance dictates an immutable type here" and every user will be happy. > compile-time slicing and arithmetic can't be performed without > special magic, an actual, potentially redundant, instance of Foo > would have to be created). Since the SMID type can't be a cdef > class, I think it's an advantage to not have it look like it is one. Details, details. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
