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. > 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
