On 20 February 2015 at 09:26, Matt Oliveri <[email protected]> wrote:
> Type theoretically, you're right. But if definitions can be
> arity-abstract, then
> 1. There is once again the question of how we pick concrete arities.
> In Shap's proposal it _was_ the definitions doing the picking.
> 2. Without further discussion, there is the fear that a closure
> allocation will somehow be introduced without it being clear from
> either the definition or the application, because the definition looks
> arity 2, but gets specialized to arity 1.
>
It should always be clear from the application.
>
> I want to talk about this, but please wait until I bring it up with a
> use case I have. I want to understand the basic system before we go
> extending it.
>
Okay.
> That imported definitions would have the same type they were exported
> at is what everyone has been assuming, I figure. Only you proposed
> anything different.
No, I did not (as we are ignoring optional alias's), the imported and
exported types would have to be concrete and the same. The point of
separating imports from exports is to allow fully type inferred definitions
to declare their concrete types and to allow fully type inferred uses to
know the concrete types in different modules. The types would have to match
at link-time. I was thinking of a use like:
module A {
f x y = x + y
export f :: fn 'a 'a -> 'a
}
module B {
import f :: fn 'a 'a -> 'a
main = print (f 1 2)
export main :: fn -> ()
}
However, the following is probably more sensible, and is I assume what
everyone else was thinking:
data module A = {
f :: fn 'a 'a -> 'a
}
module A = {
f x y = a + y
}
data module B = {
main :: fn -> ()
}
module B = {
import module A
main = print (f 1 2)
}
Keean.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
