On Sun, Feb 15, 2015 at 11:53 AM, 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? > That was not my intention. 'fn' here is syntactic noise. In the absence of some identifier or reserved word to signal the start of the type, parsing this is a mess. I did not intend anything more complicated than that. I was simply converting Geoff's syntax above into a syntax that does not have parse ambiguities. I don't yet understand your proposal of using a datatype to signal where a function call actually happens. I'm planning to ask you about it, but I'm in the middle of a large-ish household wiring job, and I'm stealing seconds to make these replies at all. I'll ask about that this evening. You wrote elsewhere that you do not consider stack allocation an effect. I agree. The problem that concerned me is that if we have (your notation): f:: a -> b -> Eff e c then the expression "f e1" occurring in a return position is not merely doing a stack allocation. It is very posisbly doing a heap allocation, which is an effect we need to be able to express. I understand your view that return values can be allocated in a specified region, but that merely converts my statement into "it performs an allocation within the return region". But if we accept the view that Geoffrey and I seem to share, which is that we will NOT do lambda injection, then that sort of partial allocation would have to be written in some explicit fashion. I do not believe that parenthesizing the application is a good choice, because in an expression like ((f a), (g b)) where g has arity 1, the programmer cannot tell whether the parens are forcing a curried call or merely serving to override the usual precedence rules (in this case, on g, unnecessarily). Offhand, I think I would prefer some form of operator for this. > 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. I didn't say that had side effects. I said they had effects. I do agree that they merely construct closure records. The effect I was thinking about was the allocation effect. Per my "return position" example above, that can't always be eliminated. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
