2 comments

[ 2.5 ms ] story [ 19.3 ms ] thread
Even if collection types, such as vectors, are immutable in your language (which BTW I think is a great idea), you can still allow element-wise assignment:

  a = [1, 2, 3]
  a[1] = 4
This works if it has a different semantics from what you might expect: instead of updating a potentially shared object, it is considered equivalent to

  a = [a[0], 4, a[2]]
That is, it doesn't modify the object 'a' refers to; rather, it updates the binding of 'a' itself. So, for example:

  a = [1, 2, 3]
  b = a
  a[1] = 4
  b[1]  -->  2
I've used a language with this property for some years, and it's quite pleasant; you don't have to worry about copying a collection before returning from an interface, for example, to protect it from being modified by the client.
That syntax certainly fixes a major problem when dealing with immutables. The mutable-like syntax I find is the cleanest way to construct complex data types.

I keep thinking about using only immutables in my language, but I don't think it will be possible. I'm intending to a be a system language, and there are simply too many situations where you need to modify data in-place. I'm struggling to see if I can still find a place for immutables in situations where they work fine.