Re: The Paradox of Partial Parametricity

On Fri, May 10, 2013 at 6:58 AM, Kevin Smith <zenparsing@gmail.com> wrote:

>
>
>>      class AsyncTable<T,U> {
>>>         constructor() {
>>>             this.m = Map<T,U>(); // encapsulation doesn't matter for
>>> this example
>>>         }
>>>         set(keyP :Promise<T>, val :U) {
>>>             keyP.then(key => { this.m.set(key, val) });
>>>         }
>>>         get(keyP :Promise<T>) :Promise<U> {
>>>             return keyP.then(key => this.m.get(key));
>>>         }
>>>     }
>>>
>>>
> The way to make this work would be to lift the value stored in the map.
>
>     get(keyP :Promise<T>) :Promise<U> {
>         return keyP.then(key => Q.fullfill(this.m.get(key)));
>     }
>
> Do you agree?  Is your premise that forgetting such a "lawyer-ly" detail
> will amount to a foot-gun?
>

It's more than my premise, it is my point ;).

If you think of .then as a being approximately .flatMap, then you might
think to do this manually. But given the behavior of .then, programmers
will as often think of it as .map-like as they will think of it as
.flatMap-like. If code like the above is needed to use .then reliably, then
its .map-like behavior is only a distraction leading people into using a
behavior they cannot use reliably. In a system with .fulfill, what purpose
is served by giving .then this dual role?



>
> { Kevin }
>
>


-- 
    Cheers,
    --MarkM