Mutable or immutable containers?

[RauliL]

Lately I have been studying programming languages which are based on immutable containers1 and I have found myself liking the idea that core container types should be immutable.

The big question is now whether we should have mutable or immutable containers in Tempearly. Mutable containers are something that people are very used to, but I think it will eventually lead into more error-prone code, especially on typeless dynamic scripting languages like Tempearly where object instances are passed around between functions and methods.

Either way we will need to have some way of making containers immutable. Either Ruby's way of "freezing" objects or Python's way of having separate mutable and immutable container classes. My opinion is that as an experiment, we should ditch mutable lists and maps altogether and work only with immutable containers.

[RauliL]

If the language only provides immutable containers, it would however be problematic design-wise since our language is not very immutable to begin with, e.g. you can assign any kind of values to every objects with attributes.

[jupelius]

Maybe we could make the containers immutable by default but also provide a way to declare mutable containers explicitly.

[RauliL]

If you have any ideas how this would be done either with syntax changes or with API let's hear 'em.

[jupelius]

For syntax I'd recommend a simple one character specifier when defining a mutable container. Example: ?list = ["one", "two", "three", "four"]; or similar

[RauliL]

Variables cannot hold information about mutability since they can hold any values and can be declared at any point of time. Thus, variables cannot hold information about the objects they reference.

More valid way of using syntax to declare container mutable/immutable would be something like this: ?["one", "two", "three"].

Then again, that could potentially cause issues with ternary operator, at least readability issues: foo ? ?["bar"] : ?["baz"].

[RauliL]

And in OO language something like that should be done with method calls. Like this:

["one", "two", "three"].freeze()

Freeze method would mark object as "frozen" which prevents further modifications on it.

This raises more questions though. Should object freezing be allowed only on containers or every type of objects? What should happen when an modification is attempted on frozen object? Should it throw an exception or just silently ignore it?

Ruby has object freezing and typical Ruby program contains shitloads of testing whether some object is frozen or not. This could become frustrating.

[jupelius]

I think silently ignoring explicit instructions is a bad thing. There should always be an error when you're trying to do something illegal.

[RauliL]

But constantly testing whether some object is mutable or not is not ideal either. That's one more reason to use only immutable containers.