On Sun, Feb 15, 2015 at 10:33 PM, Matt Oliveri <[email protected]> wrote:

> On Sun, Feb 15, 2015 at 1:47 PM, Jonathan S. Shapiro <[email protected]>
> wrote:
> > My problem here is that now we seem to be carrying a "true" function type
> > and a "hidden" function type. Not just for function definitions, but also
> > for variables, fields, and parameters of function type.
>
> Good point. But still, this is how F# basically works, no? The hidden
> type is the CLI type. When the original F# type cannot be
> unambiguously determined from the CLI type it compiled to, we need to
> remember it too.
>

Yes. But F# isn't really trying to solve the general arity problem with
their approach. They are trying to solve the interoperability problem. At
interoperability points they explicitly create a new alias that expresses a
CLI type that *does* encode arity. At that point the type isn't hidden,
which is why the whole thing works.

My impression is that within F# programs themselves, they are content with
the "we can [allegedly] optimize all this crap away by magic". My ultimate
problem with that philosophy is that it's not only an exercise in proof by
strong assertion, but one that people cling to even though it is known to
be false and ignores the distinction between optimization and specification.

Optimizations, from the standpoint of correct program behavior, are
*always* elective. Keean has proposed relying on optimizations to achieve
correct program behavior in certain places. Correctness and correct
application of such optimizations are not elective. We don't know how to
specify such optimizations rigorously!

> Arity can't be hidden this way unless we start introducing shadow
> coercions.
> > Shadow coercions are typically allocating, and it's absolutely not OK for
> > assignment to entail an allocation.
>
> Very good point. This does seem to be a problem for Keean's proposal.
> I guess F# handles this by not mapping such different types to the
> same CLI type? Or what?


F# *doesn't* handle this. First, assignment doesn't arise in the situations
where the F# solution gets applied, and second, CLI has no means to talk
about non-allocating functions.


shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to