Full closures for D

[Bill Baxter]

Nathan Reed wrote:
> Simas wrote:
>> Nathan Reed Wrote:
>>> Of course, in this case it's "easy enough to infer".  However, 
>>> function bodies can be arbitrarily complicated, meaning you will need 
>>> a full type inference engine for this to work in the general case.
>>
>> Not really. The compiler knows what the return-type is.
> 
> Not in all cases.
> 
> // What's the type of dg here?
> auto dg = { return $0; }
> 
> void some_func ( int delegate (int) dg );
> void some_func ( string delegate (string) dg );
> 
> // Which some_func is being called here?
> some_func({ return $0; });
> 
> You can't depend on the environment in which the delegate is defined 
> giving you any information about what the delegate's type should be. 
> It's only a happy accident that in the particular example with 'map' 
> posted above, the second parameter to map() tells you what the type T is 
> and therefore what the delegate's type should be.  So, in the general 
> case, you *will* need a full type inference engine to descend into the 
> body of the delegate, examine the expressions in which parameters 
> appear, and infer their types (e.g.: base ~ $0 where base is 
> const(char)[] and ~ is an operation that works on two arrays of the same 
> type, hence $0 is also const(char)[]).  And in some cases even that's 
> not enough - the identity delegate I used above, { return $0; }, cannot 
> reasonably be assigned *any* delegate type, since its parameter and 
> return could be any type at all.
> 
> I'm sorry, this idea is just fundamentally not compatible with D's type 
> system.  True, the language *could be* modified in such a way as to make 
> this work.  But that is way too far of a departure from D's C/C++ roots. 
>  It is not a scripting language.

More sophisticated type inference is certainly possible with a strong 
static typing.  When you trigger an ambiguous case like the ones you 
show above, the compiler should just tell you "cannot deduce type of ___ 
in expression ___".  Maybe with a few possible valid deductions to point 
out the ambiguity.  That's what the strong statically typed language ML 
does (and variants like OCaml).  It just happens that type inference 
hasn't historically been a big part of C/C++.  But D makes a number of 
moves in the direction of more ML-like type inference.  It's just not 
all the way there.  Deducing function return types would be a next 
logical step.

>> On "http://www.digitalmars.com/d/" D is defined as "Its focus is on 
>> combining the power and high performance of C and C++ with the 
>> programmer productivity of modern languages like Ruby and Python."
>>
>> Well, somebody may say perl isn't modern. But in Ruby and Python this 
>> is also possible. So, why is this wrong? Only why this is not C-style?
> 
> Ruby, Python, and Perl are all dynamically typed languages, and they owe 
> a good deal of their "programmer productivity" to that.  D wants to be 
> progammer-productive too, but D is committed to being *statically* 
> type-safe as much as possible.  So D will bring in only those features 
> of modern dynamic languages that are compatible with strong, static typing.

What I said above.  Aggressive type inference is perfectly compatible 
with strong static typing.

--bb