World: r3wp

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.

The opinion I presented above may be seen as "controversial", since 
it uses notions/definitions from my "Identity" article, which some 
see just a possible, but "unusual" alternative. If asked, I can be 
talked into demonstrating the fact, that the referencing structures 
don't contain any values, but, I do not want to start any flame wars 
about that, so, I reserve my right to not feel obliged to change 
the mind of all people seeing it differently.

It's all a matter of indirections and which abstraction level one 
chooses as a viewpoint. Anyway, as far as I know, value slots are 
currently 128 bits

sorry, you are right

I apologize if I am not parsing your sentences correctly, ahead of 
time.


We use the term "value slot" because that is the official term, not 
because it fully describes the situation. It's just Carl's term for 
that 128-bit structure.
 

You seem to be misunderstanding what I meant by "immediate" values: 
I meant values of the dataypes in the immediate! typeset.
>> immediate!

== make typeset! [none! logic! integer! decimal! percent! money! 
char! pair! tuple! time! date! datatype! typeset! word! set-word! 
get-word! lit-word! refinement! issue! event!]

Any type not in this typeset is not an immediate type. I don't mean 
anything else by "immediate".


Nonetheless, if you like you can think of all value slots as being 
references, but these are not necessarily references in the C pointer 
sense. For many of the "immediate" types (as defined above) these 
are abstract references. For instance, consider [1]. The first element 
of [1] refers to the abstract idea of an integer, of the value 1, 
plus some extra stuff (like no new-line attribute). However, the 
block [1] just contains a "value slot" which has a bunch of bits 
in it. We have decided that those bits refer to the idea of that 
value (integer, 1, extra stuff), but finally they are just bits. 
If you change the bits, the new set of bits would refer to a different 
idea - the original idea is unchanged, just not referred to anymore 
by the block. This is close enough to "immutable" that we can treat 
"immediate" types as such, which is helpful for reasoning purposes.


Now here is the interesting part: We can consider *all* "immediate" 
types to be immutable. The word types contain pointers (effectively) 
to a symbol and a binding. However, the symbol is immutable, and 
the binding can be considered a reference value - what the binding 
refers to may be modified, but the reference itself is not (in the 
abstract). If you change either of those two pointers, this would 
make it a new word - the old symbol and binding referent are unchanged. 
The actual binding referent is considered to be a separate value 
from the word (a object or context). So, words are still close enough 
to "immutable" for reasoning purposes.


Where it gets iffy is when we get into types that are not in that 
immediate! typeset, because the "immutable" part is only references 
and offsets, not any part of the value that we would usually consider 
valuable. For the purposes of reasoning there really isn't much of 
the value that is worth considering to be inherently "immutable", 
and such types are worth flagging when considering sharing of data 
and other stuff. This is why these types aren't in the immediate! 
typeset (and why we have that typeset predefined).


The reason the typeset is called immediate! rather than immutable! 
is because the feature of the types that we want to emphasize is 
that values of those types, when passed to functions or otherwise 
assigned to other value slots, can at least in an abstract sense 
be considered to be copied to the other value slot (even if the abstract 
idea of the value is still abstractly referred to). This means in 
particular that changes to a value slot can't affect other value 
slots that refer to the same value (at least before the change). 
For non-immediate types all or part of the value is not copied on 
assignment, so changes to the original would affect at least part 
of the value referred to by the new slot. This is the crucial difference 
for CS reasoning purposes. We don't call them "immutable" directly 
because things like using path syntax to fake mutability of tuples, 
or PROTECT making stuff immutable, tends to confuse the issue.


Where it gets even more interesting is when you consider that the 
existence and implementation of value slots is actually irrelevant 
to the behavior of REBOL; all that really matters is the difference 
in apparent behavior between the immediate! types and the rest. You 
could have boxed unique integers and decimals that are referred to 
by pointers if you like, or symbols that don't exist except as unique 
numbers, or a generational or compacting collector that changes the 
location of the referents and updates the references accordingly. 
None of that matters as long as the system at least pretends that 
the immediate! types are unchangeable and copied on assignment.

A lot of these terms are basically arbitrary, and can be considered 
by some to be not very precise, but they were all chosen for very 
good reasons. The above is the reasoning behind our use of the term 
"immediate", which is now the REBOL standard term for that concept, 
for better or worse.

Agreed

{I apologize if I am not parsing your sentences correctly, ahead 
of time.} - I think, that you did well when parsing the sentences 
;-)


{We use the term "value slot" because that is the official term, 
not because it fully describes the situation.} - maybe I am the one 
to apologize here, I had no idea it was official, I thought, that 
it was not mentioned in the official documentation...


{You seem to be misunderstanding what I meant by "immediate" values: 
I meant values of the dataypes in the immediate! typeset.} - OK, 
so, I may need to be careful, and not mention any properties of the 
immediate! values, since they are not the reason why the immeditate! 
typeset was defined?

If there are more properties of the immediate! values than the ones 
I listed above, as opposed to the other types, feel free to list 
them. I just gave an overview. As for documentation, that's a little 
behind. I was just going by how the person who writes this stuff 
refers to them. It's been used in some blogs, conversations, etc. 
It's a term taken from compiler construction jargon, appropriate 
since the semantics of REBOL has a lot of overlap with those of a 
compiler.

{Any type not in this typeset ist an immediate type. I don't mean 
anything else by "immediate".} - nevertheless, this provokes a question: 
does that mean, that no matter how these values are implemented (using 
less than 128 bits, or more than 128 bits to completely describe 
them), the typeset definition would not be affected?

ist
 - read as "is not", please, I messed the cut and paste, sorry

As long as they behave the same, sure, why not? Words have pointers 
and integers don't, but they both keep with the behavior of that 
group.

Nonetheless, if you like you can think of all value slots as being 
references, but these are not necessarily references in the C pointer 
sense.

 - correct, I do not want to say, they are references in the C pointer 
 sense, that should be emphasized".

Right. This is all an elaborate way of pointing out that we don't 
actually disagree on how things work :)