On Sat, Aug 14, 2010 at 8:48 PM, Jonathan S. Shapiro <[email protected]> wrote: > I'm going to hazard an uninformed guess on this: BitC already gives us > enough overloading capabilities to handle most of what we need. We'll need > to look at ternary operators like MUL-ADD in the mixfix handler at some > point, but that doesn't seem intrinsically hard. We'll also clearly need to > deal with explicit alignment and offsets. > > What we will not introduce is implicit conversion. That way lies insanity.
I've spent today trying to understand what the type inference is doing from the 2008 tech report. As mentioned in my initial email, my view (as a user of SIMD) is that you really want SIMD to be a way of "processing" aggregate data of simpler rather than a set of completely distinct types. (Apart from anything else, mechanisms that require you to specify types suitable for SIMD right from the beginning of the programming violate the rule that you should write code for simplicity first and then optimize hot-spots.) As such, I think the only significant requirements are 1. An explicit mechanism for telling the type system that within a given block of code, this entity is going to be "processed as" a SIMD type. (That could be using the conventional type conversion syntax providing it optimizes away.) 2. From experience, the whole signed vs unsigned thing will cause annoyances in typing/overload resolution. But that problem isn't insoluble and is best postponed until further things are being implemented. Neither of these seem in fatal conflict with the current design. Regards, David Steven Tweed _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
