World: r3wp

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 :)

I guess, that I owe a little more to the readers, so here is an example 
illustrating what I actually mean:

let's define a block as follows:

    a-block: [[1] [2]]


at the present state, it is obvious, that first a-block and second 
a-block are not identical
illustration:

    same? first a-block second a-block ; == false

now, let's use the CHANGE function:

    change/only next a-block first a-block
    a-block ; == [[1] [1]]

due to the way we did it,

and due to reflexivity of identity, first a-block and second a-block 
yield the same value,
after this operation

("the same" in the sense, that there is only one value, which happens 
to be the value both expressions yield.)


since first a-block and second a-block are two expressions yielding 
just one value,
we conclude (as a consequence of that), that the respective value
is not contained in the first slot of the A-BLOCK block

(if it were "contained" in there we could not be able to see, that 
the value is actually not "contained" in there)


Usíng the same approach for any other REBOL value, we can demonstrate, 
that no value is "contained" in "value slot". Since we *can* find 
out "Which value is the first a-block value?" there is only one conclusion 
we can make: using the first a-block expression we can refer to the 
value (this is why I use the words "reference", "refer"), but that 
does not mean, any other "reference" cannot "refer" to that value 
as well, thus the value "is not contained", but just "referenced".

Another (less useful) way to look at it is to say that no value is 
really the same as or identical to any other value, only to itself 
(the same value slot). But since that's a useless way to look at 
it, we instead compare the bits of the different value slots and 
if they match we then say that they are the SAME? (or IDENTICAL?, 
depending on how many bits we are comparing). Expediency for the 
win!

Another (less useful) way to look at it is to say that no value is 
really the same as or identical to any other value...Expediency for 
the win!

 - yes, that is where the expediency is what should win, exactly as 
 you pointed out.

(We need to have the documentation mentioning Rebol values, compare 
results of different expressions to find out whether they are identical 
or not, document whether some value is modified by some function, 
...)

no value is really the same as or identical to any other value, only 
to itself (the same value slot).

- well, the first part of the sentence is a law of logic - nothing 
can be identical with any other thing except for itself - which is 
true, and I even used that law to define the identity

The problem is only with the second part of the sentence, "trying" 
to identify Rebol values as "value slots", which is not useful, and 
wrong.

And then you defined "value" to be something referred to by the value 
slot, not what was in the value slot, or the value slot itself. Without 
that definition, your definition of "identical" doesn't work. Which 
is why that was another way to look at it, the "other" in this case 
referring to way to look at what a value is and how to think of a 
value slot.

I'm not saying that any of these definitions are wrong, but yours 
is more useful.

I should probably explain, why I added the "and wrong" part. I did 
it, since not all Rebol values are representable using 128 bits or 
less. In that case we must have more than 128 bits no matter how 
fervently we wish something else

Yeah. The main difference between what you are saying and what I'm 
saying is for that what you are referring to by values that don't 
fit in 128 bits, the values that are in the value slots are what 
I've been calling "reference values". Thus the distinction between 
"immediate" types and "reference" types. This is a similar situation 
to (primarily OOP) languages that make a distinction between boxed 
and unboxed values, except for us even the "unboxed" values are in 
a box: the value slot. Making this distinction lets us reuse the 
large amount of existing reasoning that has been applied to OOP languages. 
This is particularly helpful when we are trying to solve the same 
problems that many other languages are, but the existing research 
on those problems is being done by people working in those other 
languages. Finding comparable distinctions makes it easier to implement 
comparable solutions :)

For instance, I'd hate to have to start from scratch in creating 
a concurrency model, especially when we can start from the Go model 
instead.

> except for us even the "unboxed" values are in a box: the value 
slot.


It's the extreme semantic overloading of "value", that is the problem 
here. :)

Isn't it always? It all depends on what you value i guess :)

Boxing is no good example in this case, as it describes something 
different.

But the terminology underlying the boxing process actually is useful, 
namely value types and reference types.

The immediate! typeset in R3 captures (or at least tries to) the 
former.

And we didn't make a typeset for the latter because not existing 
in the former is enough.

And Ladislav's "Identify" article is exceedingly useful in defining 
meaningful dimensions of the term "value" in REBOL's context.

Specifying a "REBOL value" as the sum of it's attributes, for example.

One attribute common to all REBOL values being type. Other attributes 
being type-dependent.

Yup. Works great until you try to use "value" in a sentence, because 
of English's ambiguity :(

Even the actual "payload data" of a REBOL value is a type-dependent 
attribute.

(unset! or none! values having no such "payload data", for example.)

And now of course the problem is, that we refer to different entities 
as "value", depending on context. Amongst those entities often referred 
to as "value" are:
- the "REBOL value", as defined above
- the "payload data" of a "REBOL value"
- the "value slot" implementation detail

Is there a way how to mold error into nice looking string?

I mean... I can do:
>> if error? err: try [1 / 0][probe err false]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== false


but what if I would like to form the error message to look like if 
the error is really evaluated:

>> do err
** Math error: attempt to divide by zero
** Where: / try
** Near: / 0

Can we have the error message formater available or is it hidden 
for some security or other reason?

I format them myself

how... do you have a list of all available error ids?

is there any idea how to place an break point int code for debugging 
reason, and release it (continue)?

int = into

Oldes - you can try to grab them out of here, but not sure how easy 
that will be:
   probe system/catalog/errors

thanks... that's what I was looking for.

Pavel... I usually use ASK with any value/message as a break point 
while debugging. Or just PROBE is I don't need to stop the evaluation.

Sunanda: not so easy, require some binding.

So far I have this:
my-attempt: funct[code /local val][
	either error? set/any 'val try code [
		val: to-object val 
		do bind [
			print rejoin [

    "!! " val/type  " error: " reduce system/catalog/errors/(val/type)/(val/id) 
    #"^/"
				"!! Where: " val/where #"^/"
				;"!! Near: " val/near  #"^/"
			]
		] val
		false
	][
		:val
	]
] 

my-attempt [debase #ff]
my-attempt [1 / 0]

but not perfect... the Near and Where info is modified :-/

How to convert issue! to binary! in R3? I was using debase in R2, 
but it's not working anymore (I guess because of unicode).

small observation:

>> any-word? #a
== true