Functional programming

[BartC]

"Steven D'Aprano" <steve+comp.lang.python at pearwood.info> wrote in message
news:5314bb96$0$29985$c3e8da3$5496439d at news.astraweb.com...

> Think about the sort of type declarations you have to do in (say) Pascal,
> and consider how stupid the compiler must be:
>
> function add_one(x: integer):integer;
>  begin
>    add_one := x+1;
>  end;
>
> Given that x is an integer, and that you add 1 (also an integer) to it,
> is it really necessary to tell the compiler that add_one returns an
> integer? What else could the output type be?
>
> This was state of the art back in 1970, but these days, if the compiler
> cannot *at least* infer the type of the return result of a function given
> the argument types, the static type system is too dumb to bother with.

To me that is perfectly reasonable. This kind of language, while it allows
expressions of mixed numeric types, treats each kind of number type as
different: integer and real, even signed and unsigned integer, and there
might be short, medium and long versions of each! And Pascal has an
unlimited number of scalar types too.

The compiler could make a guess at what the intended result might be, based
on a hundred add_one:= assignments, all with a slightly different type on 
the right-hand-side, and perhaps choose a type that encompasses all the 
possibilities (although it might erroneously decide the result is real, 
based on one of those hundred, and use floating point for all of them).

But then someone edits the code, and this time the guess will be different!
For a static language such as this, type-discipline is important. And even
if the compiler gets it right, a human reading the code would have trouble
determining the return type, except in trivial examples like this.

Putting in an explicit return type is the simplest way to go.

-- 
Bartc