The "no gc" crowd

[Dmitry Olshansky]

11-Oct-2013 18:46, Joseph Rushton Wakeling пишет:
> On 11/10/13 16:32, Dmitry Olshansky wrote:
>> This. And exactly the same for immutable. It's interesting how folks
>> totally
>> expect complex types (like containers) to meaningfully work with all 3
>> qualifiers.
>
> It's not so much that we expect it, as that we might expect that
> standard library types would _have the appropriate design work put in_
> so that they would "just work" with these qualifiers.  (Admittedly
> shared is a bit of a special case right now that probably needs more
> work before support is rolled out.)

It can't - it's like expecting 37 to modify an become 76.
Simply put built-ins are special. Imagine a ref-counted type - how would 
you copy it (and increment a count) with bit-wise immutability?
It simply doesn't make sense. (Yes, one can keep count elsewhere e.g. in 
a global hash-table).

More importantly there is little incentive to make immutable stuff 
ref-counted, especially COW-types. In this sense BigInt simply doesn't 
work with immutable by design, if need be one can make FixedBigInt that 
doesn't include COW, doesn't support read-modify-write and mixes well 
with BigInt.

Immutable works best as static data and/or as snapshot style data 
structures. It's tables, strings and some unique stuff that gets frozen 
and published at a certain point (usually at start up).

It makes a lot less sense at local scope aside from aesthetic beauty as 
there is plenty of invariants to check, and bitwise immutability is a 
minority of that.

I would even suggest to adopt a convention for a pair of freeze/thaw 
methods for any UDT that give you a deep copy of object this is made for 
mutation (thaw on immutable object) or immutable (freeze mutable).

>
> If you tell me that's an unreasonable expectation then fair enough, but
> it feels pretty bad if e.g. library-implemented number types (big
> integers or floats, rationals, complex numbers, ...) can't from a user
> perspective behave exactly like their built-in counterparts.

No magic paint would automatically expel reference count from the 
struct's body. With shared it's even more obvious.

In general user defined type has to be designed with one of 3 major use 
cases in mind: local, immutable, shared.


-- 
Dmitry Olshansky