* * * * *
                                        
                           More fun with static types
                                        
What else can you do with typing systems [1]? And what about that relentless
drive towards multiple processor machines [2]?

One thing, better parallelization of code. One such method is the map
function [3], where some function (or code) is applied to every element in a
list, and each such application is independent of each other. In the current
crop of langauges, there's an actual function or keyword that is used:

> (DEFINE INCR (LAMBDA (X) (+ X 1)))
> (MAPCAR #'INCR '(1 2 3 4 5))
> 

This bit of Lisp code increments the elements of a list by 1. Other languages
have a similar function or library variation on map. But why? Couldn't we
have the compiler figure it out? At least in a few instances?

For instance, in C, the following will give a compiler error:

> {
>   double x[100];
>   double y[100];
> 
>   y = sin(x);
> }
> 

since sin() takes a single double parameter, not an array. But since I'm
talking hypothetical compilers here, couldn't the compiler recognize that x
is an array of doubles, and that sin() takes a single double, and since the
result is going to another array of doubles, why not just map sin() over the
array x? On a uniprocessor machine the code generated could be something
like:

> {
>   double x[100];
>   double y[100];
>   size_t i;
> 
>   for (i = 0 ; i < 100 ; i++)
>     y[i] = sin(x[i]);
> }
> 

Given a routine that expects a parameter of type X, and a variable array of
type X, passing said variable array into said routine should not produce an
error, but a mapping instead. No fence post errors [4]. No having to type out
for loops, or while loops, or loops of any kind. Or even of having to type
out “map.”

Or is this too much DWIM (Do What I Mean)?

[1] gopher://gopher.conman.org/0Phlog:2007/02/21.2
[2] gopher://gopher.conman.org/0Phlog:2005/02/18.1
[3] http://en.wikipedia.org/wiki/Map_(higher-order_function)
[4] http://c2.com/cgi/wiki?FencePostError

Email Sean Conner at sean@conman.org

.