World: r3wp

The simplified gist of what I'm after is:

Does new-line modify the 128-bit value slot? I assume so.

How do then have come to conclusion regarding the immutability of 
the new-line attribute?

In theory the immediate values are supposed to be immutable
- three objections:


- immediate values are not definable in Rebol (you can define such 
a typeset, but that does not mean, every compatible interpreter would 
need to implement them the way they are implemented in one specific 
case)

- the sentence is uninformative ("are supposed" does not mean "are")
- "in theory" is uninformative as well (what theory?)

But I think I know where I am going wrong.

Andreas, I can define a function modifying a 128-bit slot so, that 
only the sign of an integer is changed. Would you consider that relevant?

I was using the English idiomatic meaning of "in theory", not the 
scientific jargon meaning.

("define a function" == "define a function in rebol") in my above 
statement

Ladislav, if you can do that in pure REBOL, I would consider it very 
interesting at least.

Ah, thanks :)

And despite that, you maintain that the sign of an integer is immutable 
in REBOL?

Sure

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.