World: r3wp

But there must be another indirection, from the series value to the 
actual storage location of its item slots, because the item storage 
can't be counted on to stay at the same memory address over garbage 
collection and callbacks or multitasking, but it must be deduced 
that the series value can be counted on to stay at the same memory 
address

So there must be a table of series descriptors apart from the actual 
series content

Maybe it doesn't really need to be a global table, but it seems very 
convenient for the garbage collector

No, haven't heard of that.

It wouldn't need to be a global table, it could be a heap space dedicated 
to series descriptors (a typed array in memory). Same purpose, more 
likely implementation. Precise collectors are often implemented with 
type-specific heap spaces, since it reduces fragmentation when you 
don't have a copying or compacting collector - REBOL's collector 
doesn't move values, supposedly. REBOL could get away with heap spaces 
for block data, string/binary data, and descriptors (maybe both object 
and series in the same heap space); there might be more, but adding 
more can make the memory management more complicated.

I'm not sure how that differs from my description

can't be counted on to stay at the same memory address over garbage 
collection

 - as far as I know this has never been demonstrated. The performance 
 characteristics of REBOL's garbage collection are more consistent 
 with mark-and-sweep, and there hasn't been any indication that it 
 compacts or copies. Series reallocation on expansion does copy though. 
 Plus, there is a bunch of indication that R3 isn't yet task-safe 
 and that callbacks can choke on shared data too. Aside from that, 
 your argument's good, and your conclusion more so.

Well, I wouldn't count on it, but indeed, what the extensions documentation 
specifies is that series can move when they are changed. It's all 
very vague, but if the collector doesn't compact as you say, it would 
be restricted to expanding series beyond the internally allocated 
memory region

time-block? u mean delta-time?
 I mean TIME-BLOCK:

http://www.fm.tul.cz/~ladislav/rebol/timblk.r

could two different words be equal in REBOL?
 - in my opinion, that would be a bug

(unless intended, using aliasing)

heap spaces for block data, string/binary data,

 - there is absolutely no reason to have different spaces for strings 
 and blocks

aha, maybe there is

If you allocate strings only in multiples of 128 bits and aligned 
the same as blocks, fragmentation wouldn't be a problem if they are 
allocated in the same space. It would be a waste of resources for 
strings though, as even a single-char string would take 16 bytes 
of space.

Some memory management systems segregate the values by the size, 
with objects of similar sizes allocated from the same space, to cut 
down on fragmentation. Large enough objects are sometimes allocated 
on their own, in a seperate chunk of memory allocated from the OS. 
I haven't seen any indications that REBOL's memory management does 
this though.

Why does SKIP accept LOGIC! and PAIR! as its OFFSET parameter? Thanks.

pair! is for images, I think.

I have the same guess. Geomol

About logic, I guess, it's related to a wish to use PICK with logic 
argument. It works like this for SKIP:

>> skip [a b] true
== [a b]
>> skip [a b] false
== [b]

and you can use PICK instead of EITHER sometimes like:

value: pick [1 2] b > 1

instead of

value: either b > 1 [1] [2]

SKIP with TRUE as its 2nd argument, which made me think it DID skip. 
SKIP with FALSE as its 2nd argument, which made me think it DIDN'T 
skip. With your PICK example, now I understand.

Yes, the initial imagined behaviour is turned around with logic. 
:) The PICK method is also faster than the EITHER method, if it's 
simple values to pick. If you have to reduce the block, the EITHER 
method is faster, as EITHER already reduce its blocks.

In R2, you can pick from functions, like:

>> pick :to-integer 1
== [value]

and it works with true too, but not with false:

>> pick :to-integer true 
== [value]
>> pick :to-integer false
** Script Error: Out of range or past end

In R3, you can't pick functions like this.

SKIP with LOGIC value seems reverse,  because it doesn't convert 
logic to integer before use it:
>> to-integer true
== 1

See Core group!

Yep, I saw it.

LENGTH? 'WORD is 4, LENGTH? /WORD is 5 ... not 4. Why? is the heading 
#"/" in refinement counted?

I guess it counts / as part of it:
>> to-string /WORD
== "/WORD"

>> to-string 'WORD
== "WORD"

But I don't know if it is a bug or not.

To be able to type a word of datatype word!, we need lit-word!. Else 
the word would be evaluated to it's value. So when you write
	length? 'word
, it's the same as
	length? first [word]
To get what you want:
	length? first ['word]
or
	length? quote 'word

It's kinda interesting, that you can take the length of words in 
R3. You can't do that in R2.

thats right, same for refinement also.

and above code gives different result in R2:
>> to-string 'word
== "word"
>> to-string /word
== "word"

both 4 chars lenght.

Funny!

These different words are all part of the typeset any-word!. In R3, 
you can see, what datatypes are part of a typeset with:
	? any-word!

It's interesting, issue! is also an any-word! in R3. It's not in 
R2. But issues have different syntactic rules than words:

>> #1a
== 1a
>> '1a
** Syntax Error: Invalid word-lit -- '1a

Correction:

>> #1a
== #1a

Same can be said with refinements:

>> /1a
== /1a

which looks to me like an error.

it is because of lit-words cannot start with a number but refinements 
and issues can.

Yes, but what benefit do you have from refinements starting with 
a number?

actually nothing :)

it is useless because you can create a function like below, but you 
cannot use it:

>> f: func [/1a] []
>> f/1a
** Syntax Error: Invalid integer -- 1a

IIRC it was discussed that numeral refinements should be removed 
from R3.

in the source code of load-module, the first line is ASSERT/TYPE 
[LOCAL NONE!]   ... Why?

Geomol, refinements are not just for translating to paths. You can 
use a subset of the possible refinements for that purpose, but rest 
can be used for whatever reason you like in other dialects. REBOL 
is not just the DO dialect, remember. (This is the official answer; 
I am just writing it out again, for the 4th time this year.)

Maxim, it was discussed and that proposal was rejected.

Jerry, the /local refinement is just another function option. If 
you provide that option when you call that function, you can provide 
initial values for the "local variables". In the case of sys/load-module, 
the security and control flow of that function depends on the local 
variables being initialized with the none value, so we want to avoid 
the /local option being used when the function is called. When a 
function refinement is not used its value is none, so if you want 
to ensure that it is none and trigger an error if it isn't, ASSERT/type 
[option none!] is the most efficient way to do this in R3.

After Carl asked me that question, Jerry, and got that answer, he 
wrote a blog where he suggested making /local special in functions. 
While most people are in favor of that (not half of the gurus), this 
proposed change to /local hasn't been done yet and we don't know 
if it will ever be done.

Thanks very very much, BrianH.

(This is the official answer; I am just writing it out again, for 
the 4th time this year.)

Why bother? No matter how many times you write it, this still is 
bad design. Or lack of design and bad implementation. It's like having 
integers, you can only use for the PICK function, but can't make 
arithmetic with.

After Carl asked me that question, Jerry, and got that answer, he 
wrote a blog where he suggested making /local special in functions. 
While most people are in favor of that (not half of the gurus)

 - then I must have a problem with reading comprehension. I rechecked 
 the discussion of this twice and came to a completely different conclusion

My numbers as seen from the discussion:

discussing: 11
for the change: 0
against the change: 2
neither for nor against the change: 9

I did not try to categorize the votes futher to guru/non-guru, btw

I'm looking at what kind of functions, R3 has:
>> ? any-function!

ANY-FUNCTION! is a typeset of value: make typeset! [native! action! 
rebcode! command! op! closure! function!]


And then I come to think, if it's a problem having both native!, 
action! and function!. Should all 3 be seen as function! ? Having 
them all and now with the addition of closure, what if a native act 
like a closure? Should it then be a native-closure! ? Same with action! 
.


And what if it's possible one day to make operators, should we then 
call the current operators for nop! (or native-op!)? I guess, these 
types originated, because they're dealt with differently internally, 
but should the users have to deal with the differences?