On 20 February 2015 at 03:48, Jonathan S. Shapiro <[email protected]> wrote:
> On Wed, Feb 18, 2015 at 3:36 PM, William ML Leslie < > [email protected]> wrote: > > >> BTW I wrote my email after reading your concrete proposal, but like I >> said, it only talks about applications and parameters and doesn't really >> deal with return values (or case expressions or any other kind of meet). >> Say, you said that paramaters and return values could be abstract, and then >> only talked about inference rules for parameters. >> > > It "falls out" through unification as follows: > > 1. The only way that a function *definition* can return an abstract type > is by returning some computation based on one or more parameters that have > abstract type. Any use of such a function will necessarily concretize the > parameter, and therefore the return type. > > 2. A program that still references abstract types after linking is > underspecified, which is an error.[*] > > [*] We can stretch this to deal with dynamic loading if we must. As long > as nobody actually sees the tree fall... > > > 3. All other cases are transitively resolved by unification. > > > Does that address the concern? > Sure, thanks. I think it would also minimise confusion if the constraint was required in the signature where it exists. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
