You are right, I have revised my position. I am now suggesting that a datatype be used to represent the actual point that a call happens. As in:
f :: a -> b -> Eff e c Note although Eff looks like a monad, and happens to have the semantics of a monad, this is an emergent property, you don't have to generalise it into a monad :-) Keean. On 15 Feb 2015 18:30, "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. > > > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
