SIMD support...

[Andrei Alexandrescu]

On 1/6/12 5:52 PM, Walter Bright wrote:
> Support the 10 vector types as basic types, support them with the
> arithmetic infix operators, and use intrinsics for the rest of the
> operations. I believe this scheme:
>
> 1. will look better in code, and will be easier to use
> 2. will allow for better error detection and more comprehensible error
> messages when things are misused
> 3. will generate better code
> 4. shouldn't be hard to implement, as I already did most of the work
> when I did the SIMD support for float and double.

I think it would be great to try avoiding the barbarism of adding 10 
built-in types and a bunch of built-ins.

Historically, D has erred heavily on the side of building in the 
compiler. Consider the the complex numbers affair, in tow with crackpot 
science arguments on why they're a must. It's great that embarrassment 
is behind us. Also consider how the hard-coding of associative arrays in 
an awkward interface inside the runtime has stifled efficient 
implementations, progress, and innovation in that area. Still a lot of 
work needed there, too, to essentially undo a bad decision.

Let's not repeat history. Months later we'll look at the hecatomb of 
types and builtins we dumped into the language and we'll be like, what 
were we /thinking/?

Adding built-in types and functions is giving up good design, judgment, 
and using what we have creatively. It may mean failure to understand and 
use the expressive power of the language, and worse, compensate by 
adding even more poorly designed artifacts to it.

I would very strongly suggest we reconsider the tactics of it all. Yes, 
it's great to have SIMD support in the language. No, I don't think 
adding a wheelbarrow to the language is the right way.


Thanks,

Andrei