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.


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. :-)


shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to