After a little thought, it seems to me that calling a function that can produce side effects is monadic, not co-monadic, based on the simple understanding that monads generate (side-)effects, and co-monads consume contexts.
I guess one could consider a set of pre-defined resources passed as a context to a co-monad, as opposed to a set of generated effects, but I at least understand what is going on in the monadic case better. So I would probably prefer: x y z -> Fn (a b -> Fn w) to Fn x y z -> Fn a b -> w but I would be persuaded otherwise... Keean. On 15 February 2015 at 19:53, Keean Schupke <[email protected]> wrote: > > On 15 Feb 2015 19:29, "Geoffrey Irving" <[email protected]> wrote: > > > > On Sun, Feb 15, 2015 at 11:06 AM, Jonathan S. Shapiro <[email protected]> > wrote: > > > Geoffrey: > > > > > > The syntax for types may need multiple arguments to the left of *any* > arrow. > > > So, for example, we might see > > > > > > x y z -> a b -> w > > > > > > Note that this is merely a syntactic variant on my original proposal, > which > > > would write this as: > > > > > > fn x y z -> fn a b -> w > > In this case "fn" would appear to be a comonad? Is a comonad a better > choice than a monad? > > > > > Yep, I also like that syntax. > > > > > OK. So let's now assume this notation for a second. Are we still > permitted > > > to do a curry-style application? That is, given > > > > > > def f x y = ... returning z > > > > > > is the application > > > > > > f 1 > > > > > > acceptable (assuming the first parameter type admits int)? To put this > > > another way, are we doing implicit lambda insertions to satisfy > coercions > > > here, or are we requiring explicit insertion? I think that (at least > for > > > now) it should be explicit. > > > > Given the complexity of this thread, I'd also learn towards explicit: > > "f 1" would not be legal. > > Yes, this seems sensible, so lambdas have to be explicit... > > Keean. > > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
