On Sun, Feb 15, 2015 at 1:30 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sat, Feb 14, 2015 at 11:35 AM, Keean Schupke <[email protected]> wrote: >> >> On 14 Feb 2015 16:39, "Jonathan S. Shapiro" <[email protected]> wrote: >> >> > I don't think that works. If we take the position that implementation >> > and type should be firmly separate, then when I see a function in a module >> > signature, how do I know it's arity? >> >> Because you import the function by its native arity, and give it a local >> alias with the arity you want to use. > > > I feel like we are going around in circles here. Given that the only thing I > can see in the module signature is the type, how is it possible for me to > know the native arity? > > Creating the alias isn't a problem. The problem is: how do I know the arity > when it isn't encoded anywhere and the type doesn't tell me? > >> No, I am saying at the module boundary you see both the native-arity and >> the local-arity. At the module boundary you import the function with the >> native-arity, and supply a local type alias (with whatever calling >> convention you want) that applies inside that module only so: >> >> import 'C' add :: (int32, int32) -> int32 as int32 -> int32 -> int32 > > Hang on here. I'm not trying to import a C function! I'm trying to import a > BitC function! Even if it's been reduced to a single argument pattern, I > don't know it's native arity: > > import 'bitc' myFunc :: (int32, int32) -> int32 -> int32 > > could have a nativer arity of [2, 1] -> 1, or could equally well have a > native arity of 2 -> 1 -> 1. > > So how do I know the native arity here? >> >> We know the native arity of 'g' from the module import statement. > > So you said above, but I'm bewildered why you think so. I understand why > what you suggested works in the case of C, but that isn't the case I'm > trying to understand here.
His proposal confused me at first too. He actually just determines the native arity from the surface type in a consistent way. Type aliases are not for controlling the native arity, they're for hiding it! And as he points out, they also give you a cost-free way of adapting curried-looking functions into tuplized-looking, or vice versa. This would ostensibly help with divergent library styles. Originally he was using the convention that curried args are never natively passed at once, but tuplized args always are. Now he's proposing some monadic-looking stuff that I don't like. >> > Until somebody explains to me how to reconcile monads and concurrency, >> > we can't go there. Even if we *can* explain that, there are still concerns >> > about monad composability. >> >> So lets start with composition. You need 'set' types in the type system, >> then you can have a monad (lets call it Eff) that is parametric on a set of >> types: > > No, respectfully, let's not. Monads are a whole separate can of worms for a > separate discussion thread. Let's get the arity discussion finished first. Oops. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
