World: r3wp

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.

In the hostkit/extensions we the type as 8-bit byte.

So it probably is less than 8.

(<=)

What's the largest "immediate" datatype in R3?

80 bits for tuple!, 96 bits for money!.

More than 80 for tuple - it has a length attribute in there somewhere.

AFAIK 96 bits are reserved for immediate values with the 32 bits 
left for flags and stuff.

this was hinted at when the decimal pair was being worked on. IIRC

Would make sense.

Considering that typeset! is supposedly immediate as well, we'll 
probably have 6 bits for the type.

This is why I mark any suggestion to introduce a new datatype with 
the major flag in CureCode. We have a budget.

Considering that typeset! is supposedly immediate as well, we'll 
probably have 6 bits for the type.

 - I do not follow. I my calculations are correct, then the typeset 
 could have 96 bits, which means 96 different types at most. Nevertheless, 
 96 different types would need 7 bits, 6 is not enough.

Yes, also a possibility.

Nevertheless, these limits may change, if the interpreter is compiled 
for a 64-bit environment, where the available space can increase...

Just a summary of the above "directly modify the slot" readers/watchers, 
that might not understand the whole discussion:


1) In REBOL some values, like blocks, maps, etc. can refer to other 
Rebol values. It is not reasonable to call the referring substructures 
"value slots" (I don't think I disclose too much when I say, that 
these referring substructures are 256-bit "wide"), since it can be 
easily demonstrated, that the substructures in fact don't "contain" 
the values, but rather they refer to them. (this is obvious if the 
value referred to is any of the values, that simply cannot be described 
by less than 256 bits) but is true also in case the value could eventually 
be described in less than 256 bits. (Brian calls such values "immediate", 
but I dislike that notion, since the values Brian calls "immediate" 
cannot, in fact, "fit in" the referring substructures either, and 
everybody having read my identity article knows enough to be able 
to do that as an exercise.).

2) Andreas asked in the discussion above, whether the possibility 
to "directly modify" the referencing substructures does not make 
all REBOL values mutable. The answer was "no", one of the resons 
is the fact, that the ability to "directly modify" the referencing 
substructures makes all values containing them mutable, which means, 
that REBOL blocks containing modifiable referencing substructures 
are mutable, etc... Any modification of the reference substructure 
is a mutation of the value containing the substructure, but cannot 
be a mutation of the value referenced by the substructure exactly 
because the substructures don't contain any values.