Re: the forward method [dynamic vs. static typing]

["Felix Klock's ll1 list proxy" <address@hidden>]

I'm a (big) fan of ST, but I don't think this is a very convincing 
example from Ken.

I firmly believe that DT *can* get this effect, if you define your 
types and primitive operations appropriately.

Example: define the type Answer to be a *product* of [Maybe Double] and 
[Maybe Bool] (product, not sum; in other words, use records, not 
unions).    [Maybe X] is the tagged sum of (Just X) and Nothing.

Then make _read_ parse its data, filling the slots of the Answer with 
any sensible value it can interpret the input as being for that context 
(I believe Ken's read has the same issues; it just makes the decisions 
at compile-time rather than run-time).

Also, make _/_ and _not_ work on Answers, not type specific values.  
e.g., _not_ takes an Answer, and negates the Bool slot, and fills the 
remaining slots with Nothing, throwing away their prior values.

By the time any of the Answers below get to _print_, they'll have only 
one valid slot in the Answer.  (And if you counter with "well what 
about other code", I response, "what will Ken's system do with 'getLine 
 >>= print . read' ?"   I honestly don't know the answer to that; it 
seems to me that you have the same challenges there).

So, with an appropriate definition for your primitives, you can get the 
same code in a DT system.  And yes, it is a pretty esoteric definition, 
but I find static dispatch based on return-type to be *extremely* 
esoteric feature, so you just end up getting your pick of "esoteria."

-Felix

On Dec 10, 2003, at 10:23 AM, Pascal Costanza wrote:

> Ken Shan wrote:
>
>> Static typing can make programs more concise: I can write
>>     getLine >>= print . (/2) . read
>> or
>>     getLine >>= print . not . read
>> rather than
>>     getLine >>= print . (/2) . readDouble
>> or
>>     getLine >>= print . not . readBool
>
> Nice and convincing example. It seems to me that you can only get this 
> effect in a DT language by implementing your own type inferencer.
>
> Thanks,
> Pascal
>
> -- 
> Pascal Costanza               University of Bonn
> mailto:costanza@web.de        Institute of Computer Science III
> http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)