On Tue, Dec 23, 2014 at 3:24 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Dec 23, 2014 at 12:25 PM, Geoffrey Irving <[email protected]> wrote: >> >> On Tue, Dec 23, 2014 at 12:14 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> >> > Hmm. I still think this is shallow immutability, but I'm starting to see >> > the >> > problem. I'd argue that the real problem here is that bad() takes its >> > argument by name. I'm not sure whether Scala actually means to be saying >> > 'pass by name" (in the sense of Algol) or "pass by reference". The >> > difference is subtle, and there are tricky security implications to pass >> > by >> > name. Whether your case is deep or shallow depends (I think) on whether >> > "bad" and/or "error" are boxed. >> >> This example is shallow immutability, but it would become deep >> immutability if error was a field in a captured struct. > > > I think we're on the right track, but your statement above isn't quite > right. A field within a struct is exactly as shallow as the containing > struct. It's only when a reference is crossed that we start dealing with > deep immutability. So if the field were of the type: > > error : ref mutable ErrorType > > then we'd be dealing with deep immutability.
Yep, that makes sense. >> Scala's "by name" parameters are just sugar for passing a >> >> parameterless closure. For purposes of this discussion, the code is >> really just bad(() => error). > > OK. But that reduces it to a previously unsolved problem, because that's an > escaping closure. > >> > Sounds like the absence of effect types is biting you here. >> >> Yep, sufficiently powerful effect types solves all these problems. >> Sufficiently powerful might be hard to arrange in some cases, but >> that's a different question. Not sure if this is the right time to >> discuss it, but the canonical example would be: will the effect system >> be able to implement a lazy data structure that seems pure from the >> outside? Feel free to ignore/table that question. > > Since BitC isn't a lazy language, I really doubt it. :-) That's why the question is whether the user can *implement* a lazy structure on top of the language. I.e., a mutable struct with two fields: (1) a thunk and (2) a cached value. When forced, the cache is populated by evaluating the thunk if necessary, then the cache is returned. Multiple calls don't evaluate the thunk twice. If the type system enforces purity of the thunk, a lazy value would appear pure on the outside even though the implementation (in bitc, not in the bitc compiler) is imperative. Pure at least in practice, but pure to the type system only if the purity analysis is precise enough. Not sure whether this is hopeless or not given the practical power of an effect system, but if it isn't it's an important issue to keep in mind. Any other application of caching as an optimization on top of a purely functional algorithm has the same issue. Actually, I probably do know that it *is* hopeless: establishing purity requires checking a fairly complicated idempotency property. Alas. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
