On Fri, Feb 20, 2015 at 4:57 AM, Keean Schupke <[email protected]> wrote:
> 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.
That would be a dual option to what I think Shap proposed. I'll
probably bring it up when I ask. You are aware that most functions
calls will be to statically-known functions, which means we'll already
know the arity in Shap's scheme, right? This arity specialization
primarily helps with higher-order functions. Specializing based on
application would probably end up doing a lot more specialization in
practice.
>> 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)
> }
Oh I see. You're right, I'm pretty sure BitC will be more like your
second code chunk. Modules will compile to code and metadata, where
the metadata is used to compile importing modules. This is like CLI,
and many other separate-compiled languages other than C/C++.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
