On Sun, Feb 15, 2015 at 2:46 AM, Keean Schupke <[email protected]> wrote:
>
> On 15 Feb 2015 05:44, "Matt Oliveri" <[email protected]> wrote:
>>
>> So I guess what you're saying is to use tuplized functions at module
>> boundaries. Then
>>
>> On Sat, Feb 14, 2015 at 2:35 PM, Keean Schupke <[email protected]> wrote:
>> >
>> > On 14 Feb 2015 16:39, "Jonathan S. Shapiro" <[email protected]> wrote:
>> >>
>> >> On Fri, Feb 13, 2015 at 12:35 PM, Keean Schupke <[email protected]>
>> >> wrote:
>> >>> def f (g : 'a -> 'a -> 'a) x = g x
>> >>
>> >>
>> >> Note that all you have for g here is it's type, which (per your desire)
>> >> does not convey arity. We know enough to apply g to x. We don't know
>> >> enough
>> >> to know whether that application allocates or not. This is true because
>> >> we
>> >> don't have enough information to know whether it is a partial
>> >> application.
>> >
>> > We know the native arity of 'g' from the module import statement.
>>
>> Which module import statement? g is not imported from another module,
>> it's a local parameter. If you mean other modules' imports of f, then
>> what is f's inter-module type so that it knows the native arity of its
>> argument?
>
> If it is not a foreign function its native arity is whatever is used in its
> definition, it could use tuples an any combination like:
>
> h :: (int32, int32) -> (int32, int32) -> int32
>
> You would determine the native arity to be (2, 2) ie h is a function you
> pass two ints to, and it returns a function h' that also takes 2 ints and
> returns an int.
I think you're misunderstanding my question. Also, please don't switch
to a different example; let's stick with f. Shap chose it because it
takes a function parameter, which is what I'm asking about.
As defined, the inferred type of f is ('a -> 'a -> 'a) -> 'a -> 'a -> 'a.
When f is called from another module, what native arity must a closure
be in order to safely pass it to f?
What native arity is assumed of the parameter g when compiling f?
Note that the answers to the above two questions must be the same, but
one answer must come from the compiler of a module importing f, and
one must come from the compiler of the module defining f.
How does your scheme ensure that these answers will always be the same?
And finally:
In your scheme, what does the programmer do to control the native arity of g?
>> Anyway, how is this business of using different inter-module types any
>> better than using an arity-aware type system for compiled modules, or
>> automatically tuplizing functions under the hood?
>
> Hmm, the type system is arity aware, the exact arities are encoded in the
> types using tuples.
OK, I can use that point of view. The comparison I was asking for is
essentially the same, whether you use arities or unboxed tuples under
the hood.
> With regards to automatic tupelization, you might be coding in a tupelized
> style and want to import a library of curried functions and not have to mix
> styles (or import a library of tupelized functions and use them in a curried
> style). Doing this automatically like F# works only one way, and seems a
> little permissive as automatic tupelization may not work (or even be desired
> in some code that relies on hoisting part of a curried application outside
> of a loop for efficiency).
By automatic tuplization, I mean the user can use either tuplized or
curried functions, and the compiler will decide, based on the
definitions, what the type should've been to best avoid closure
allocation. Usually this means turning curried functions into tuplized
ones. This changes their types, so both the original "surface" types
and "tuplized" types are recorded in the compiled module. When
importing a module, the functions still appear to the programmer to
have their surface types, but the compiler also knows their tuplized
types, so it can generate the correct call code.
The main difference I see between what I've just described and what
you're calling for is that you do not store the surface types in a
compiled module, so the importer picks their own surface types to use.
> What I am suggesting is that there is a real function signature, which is
> that exported by the defining module, or 'C' code, and a local - alias which
> is the single valid signature used in type checking 'this' module.
I understood that. I was referring to the "real" signature as the
inter-module type. It's analogous to the "tuplized" type in the
automatic tuplization proposal above.
> I don't
> like the idea of multiple overloads of what should be a single function
> definition with different types.
You mean one piece of functionality is exported at multiple types
using wrappers or code duplication? I don't think anyone proposed
that.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
