World: r3wp

My definition of mutability does not depend on that

Yes, I'm starting to understand that.

I consider the new-line attribute to be an attribute of the value 
slot, that just gets copied over to new value slots when the value 
is copied. But you could consider it to be part of the value that 
doesn't affect anything other than display. It's mutable if the value 
slot is not protected, but the mutation doesn't get carried over 
to the copies, so it's what we generally call "immutable" in REBOL: 
It's just assigning a new value to the value slot.

Well, my POV is expressed in the article, and it differs from yours, 
as you may have spotted, Brian.

Ladislav, wouldn't changing the sign bit in-place affect the "numeric 
representation" attribute, and therefore make that attribute volatile?

I guess that's where I was going with the "observable".

And here it's getting a bit philosophical, so I leave it at that.

Hmm, actually, not. That is exactly where my POV differs from yours, 
as well as from Brian's. Let's consider a value 1 being "stored" 
in a block B (whatever that means). Now, if the block B is not protected 
in some way, I am able to replace the value by, say #[none] e.g. 
Does that mean I mutated the value 1, mutating the slot? Actually, 
what I mutated was just the block B, replacing 1 by #[none], but 
I did not even attempt to mutate 1, if you are still with me.

Yes, I follow.

far that matches what I said above.

So far

So, while "directly mutating the 128-bit slot", I did not mutate 
the value it contained before.

In another reality, you of course did mutate the value.

Only that it's not of any importance to call what you mutated "value".

In another reality
 == depending on the definition used

Yes, exactly.

So, for example, if we talk assembler you would of course use an 
XOR instruction to mutate the new-line bit of the value slot.

In my definition, I mutated a value, but it was the block B, not 
1

Yes.

And I think the point why your definition makes a lot of sense is 
that we can neither observe nor does it matter, if the new-line bit 
is modified directly by XOR or a MOV,XOR,MOV sequence.

if we talk assembler

 - well, I actually do not have any problem to use the same definition 
 there - if I mutate the memory, I say, that I mutate the memory, 
 not the value it contained

and what happens when you mutate the memory of the value it contained? 
 nuclear holocaust  ?  ;-)

And of course I think we also agree, that the new-line bit being 
observably a value attribute is an implementation detail that should 
not leak through either.

hmm, but it does leak, as opposed e.g. to the "immediateness" of 
values, which does not leak, in fact

Yup. That matches what I said. We use the term "immutable" for these 
values because mutations to a value slot don't propagate to other 
value slots, and assigning a value to a value slot makes a copy. 
This is useful when compared to "reference" types, where the "value" 
is not copied, just the reference, so changes to the value are seen 
by other references. In R3 we now have real immutability of value 
slots as an option, but that doesn't affect the "immutability" of 
values that we had before. And for the purposes of reasoning about 
the language using CS methods, the "immutability" of values we had 
before is close enough to be considered a useful distinction.

Or in Brian's words above, the new-line attribute should not get 
copied over to new value slots when the value is copied.

I don't see a problem with copying the new-line attribute. Without 
that we wouldn't be able to format our code and make it stick.

I don't see that problem.

Copy the new-line attributes when you copy a container where the 
items' new-line attribute is display significant.

_Where_ the new-line attribute is stored should not leak. The current 
behaviour resulting from the _existence_ of the new-line attribute 
is perfectly fine.

What is more serious, though, is the fact, that we have lesser values, 
than possible line break positions

Brian, as an aside: by "we now have real immutability of value slots 
as an option" you mean PROTECT?

? I'm having trouble following that sentence (no offence intended). 
What do you mean?

Andreas, yes, that is what I mean.

[1 2 3 4 5 6] I see seven positions for possible line break(s)

Does a value slot have a protect bit?

Again, in theory, through the PROTECT bugs are a counterargument.

Value slots of objects can be protected individually. Value slots 
of blocks are protected as a group.

My point would be: are the value slots really immutable, strictly 
speaking, or is there still a mutable protect bit?

Ladislav: Yes, we can't control the new-line at the tail.

I don't know whether the protection is in the value slot itself, 
but I doubt it because the peotection doesn't propagate when you 
assign the value to another value slot.

(Ladislav: if that is what you were going at.)

Yes

As an example of the CS tricks that immutability gives us, protecting 
a series should make it safe to share between R3 tasks without needing 
to copy it or synchronize access. That's nice :)

can we still "unprotect" ?

See the PROTECT bugs. The problem is that once the PROTECT tickets 
are all implemented, we will have a sufficiently capable system, 
but it will be too difficult to use. I think we need to rethink the 
model a little when we do the security/multitasking revamp.

The underlying model is good; the functions are awkward.

Any idea how many bits are currently used for the types attribute?

(In R3, of course.)

There are currently 56 types that we can see, so at least 6 bits 
rounding up. 8 would be generous.