On 15 Feb 2015 19:06, "Keean Schupke" <[email protected]> wrote: > > > On 15 Feb 2015 18:59, "Jonathan S. Shapiro" <[email protected]> wrote: > > > > On Sun, Feb 15, 2015 at 10:37 AM, Keean Schupke <[email protected]> wrote: > >> > >> 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 :-) > > > > > > :-) > > > > OK. First, I agree that some variant of this works. But it appears to me that this is equivalent to introducing a second arrow type, which might (perhaps) be written as: > > > > f :: a -> b -=-> c > > So are you going to have a different arrow for each different effect type? Datatypes can be parametric, and take part in type classes and constructor classes. Whilst I can imagine something similar for arrows it would appear to be not well explored in type theory. I would rather stick to more widely understood ground. > > > > > And if that's what we're doing, then it seems to me that all we have accomplished is to encode the arity using a different syntax than the one that I originally proposed. > > We have encoded arity in type semantics not just some arbitrary syntax. > > > > > Incidentally, those "accumulating" arrows *do* have effects! They cause allocation! > > No, because they are side effect free, you can memoise their results, or calculate at compile time. The absence of side effects means you can rearrange without any allocation. If they have side effects then they must be declared, or they will be inferred. >
Slight retraction, I am ignoring stack allocation, as you cannot call a function without stack allocation. You could consider stack allocation an effect, but I am not sure its a good idea. I could imagine a class of inlineable functions that could be totally allocation free which might be useful for exception handlers where stacks may have overflowed (double exception handlers). Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
