Val not immutable ?

Robert James wrote:
> It seems to me that a val is unassignable, but not immutable. Is this correct?

Yes. Think of val as an immutable reference referring to a possibly
mutable object.

> Is this an ideal, or simply that it's very hard to enforce that no
> method on the val or any if its members or members' members would
> mutate along the way?

That would require an effects tracking system, a more complex thing than
simple immutable references. Chances are it might be added to Scala in
the future.

> What is the preferred convention when we have an object that we will
> not assign to, but will mutate: make it a val or a var?

If only the object mutates, not the reference, make it a val.

/Jesper Nordenberg

Robert,

A statement of the form

val aLocation = Expr ; P

says that aLocation is not "assignable", but does not say that Expr does not evaluate to something that is mutable. What is being enforced is that aLocation may not be mutated, not that whatever Expr evaluates to may not be mutated.

Roughly speaking, the semantics of the statement is given by

[| val aLocation = Expr ; P |]
= let aLocation = [| Expr |] in [| P |]
= (lambda aLocation.[| P |])( [| Expr |] )

Best wishes,

--greg

On Tue, Aug 11, 2009 at 4:39 PM, Robert James <srobertjames@gmail.com> wrote:

It seems to me that a val is unassignable, but not immutable.  Is this correct?

Is this an ideal, or simply that it's very hard to enforce that no
method on the val or any if its members or members' members would
mutate along the way?

What is the preferred convention when we have an object that we will
not assign to, but will mutate: make it a val or a var?

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

Robert James wrote:
> It seems to me that a val is unassignable, but not immutable. Is this correct?
>
> Is this an ideal, or simply that it's very hard to enforce that no
> method on the val or any if its members or members' members would
> mutate along the way?
>
It's not hard. Some languages do it (see effect systems). There have
been talks about an effect system for Scala.

> What is the preferred convention when we have an object that we will
> not assign to, but will mutate: make it a val or a var?
>
>
The convention is often "Use val where you can. When you cannot, all
bets are off -- live with the consequences."

Vals are immutable, but the things being referenced by vals are not
necessarily immutable. These facts are orthogonal, and doesn't diminish the
utility of val.

> Is this an ideal, or simply that it's very hard to enforce that no
> method on the val or any if its members or members' members would
> mutate along the way?
>

If you wish to enforce this, you pretty much need to enforce that the object
itself be immutable. This isn't hard, and there are plenty of examples in
the Scala library. Indeed, I would say that it's good Scala style for most
but not all of your objects to be immutable.

> What is the preferred convention when we have an object that we will
> not assign to, but will mutate: make it a val or a var?
>

A val. Any immutability that you can verify is good immutability, for a lot
of excellent reasons.

On Tue, Aug 11, 2009 at 4:39 PM, Robert James <srobertjames@gmail.com> wrote:

It seems to me that a val is unassignable, but not immutable.  Is this correct?

Is this an ideal, or simply that it's very hard to enforce that no
method on the val or any if its members or members' members would
mutate along the way?

It's that it's a challenging problem to incorporate an effects system that is both sound and easy to use.
 

What is the preferred convention when we have an object that we will
not assign to, but will mutate: make it a val or a var?

The convention is to make everything a val that you can.  Since val doesn't promise that the target object is immutable there is no convention that references to mutable objects should be var and no reason to make them so.

On 8/11/09, James Iry wrote:
> The convention is to make everything a val that you can. Since val doesn't
> promise that the target object is immutable there is no convention that
> references to mutable objects should be var and no reason to make them so.
>

All replies agreed on this. But I'm quite surprised (and confused):
That means that I can't assume substituability (ref. transparency -
equals substituted by equals are equal) even on vals.

Wouldn't it make sense to let var warn about mutability, and keep vals
for the truly pure? Otherwise, seeing "val" doesn't really help me
reason about the code - it may still switch out from underneath me.

> Otherwise, seeing "val" doesn't really help me
> reason about the code - it may still switch out from underneath me.

it does seem about as toothless as final in Java.

On Tue, Aug 11, 2009 at 5:52 PM, Robert James <srobertjames@gmail.com> wrote:

All replies agreed on this.  But I'm quite surprised (and confused):
That means that I can't assume substituability (ref. transparency -
equals substituted by equals are equal) even on vals.

In any of the impure functional languages (Scheme, SML, OCaml, Scala, etc) that's right.  Referential transparency is nowhere guaranteed or proven.   In SML you create a mutable reference with something like

val foo = ref expression (* actually an immutable reference to a mutable cell, but that's not really that different *)

an immutable reference is created as in Scala

val foo = expression

But even in the later case, the result of 'expression' could be a mutable "object" - one that in turn contains refs.

 

Wouldn't it make sense to let var warn about mutability, and keep vals
for the truly pure?

Nope.  val isn't about convention,  it's about guarantees.  It's just that the guarantee it provides is small.  var means you can change the reference to point to something else. val means you can't.

Let me give you an example.  If my object includes a reference to a Counter, I don't want to swap Counters in and out but I probably want to increment the Counter.   In fact, swapping the Counter out might violate some important monotonicity guarantee I have about the behavior of my Counter - I expect it to always increase but swapping it with another Counter can make "my" Counter suddenly appear to decrease.  Within that design "val" is exactly the right thing to use and "var" is totally wrong.

Anybody who told you that functional programming languages promise referential transparency has sold you a bill of goods.  Most of the languages that have historically been called functional do not do so (the ones that do we call purely functional).

On the other hand, even the impure functional programming languages do tend to ENABLE you to create useful referentially transparent code in areas where imperative languages either prevent it or at least fight you.

> Otherwise, seeing "val" doesn't really help me
> reason about the code - it may still switch out from underneath me.
>

It's better than nothing, albeit not perfect. Such is the state of the
fallen world we inhabit, tasked to build skyscrapers out of clay. On the
other hand, that's why they pay us the big bucks, putting shoes on my
daughter's feet and butter on my whole wheat bread. If that's not what
you're looking for, well, if you want Haskell, you know how to find it...

--Dave Griffith