World: r3wp

Pavel, i'm talking about the new implementaion of blocks in R3 (it 
was addressed to Brian). There is no empty space in the middle of 
a block, never.

I have no clue about low level implementation of blocks, but if it 
would be double linked list (from C algorithm POV) it wpould be possible, 
but you are right, doesnt mention it

The double linked lists was used to implement list! type in R2, not 
blocks.

OK

I'm afraid I don't know more about R3's blocks than I've already 
said here - for more, ask Carl. That optimization sounds sensible, 
Steeve, but I don't know whether it is implemented, or what the performance 
tradeoff would be.

Brian, Vector datatype can't be expanded or appended, ie the size 
is fixed in the moment of creation, for use as fix lookup maybe good, 
practically not, it is kind of series and should behave similarly

IMO

there is lot of missing features related to vectors (find, mold, 
to binary!, etc...) It should have the same capabitilies than other 
series...

they are clearly not finished, it's not bugs

Some are missing features, some are bugs. For example, this one:

>> v: make vector! [- decimal! 32 100]
== vector!

>> v/0: 0
== 0

>> v/0
== 49151558502227733

Or this one:

>> v: make vector! [+ integer! 16 100]
== vector!

>> v/0: 20
== 20

>> v/1: 100
== 100

>> first v
== 100


See? I said that introducing zero based series in REBOL is not good 
idea :)

I don't like Zero based indexing too. We are imo opening can of worms 
here.

I really don't understand, how guys might like new 'pick behaviour. 
The example given looks like very bad desicion was made. Why was 
it added? To enable various forms of loops over series?

Pekr, read my response in the blog post.

Yes Pekr, this has nothing to do with zero based indexing. Series 
are still one based:
>> b: [a b c d e]
== [a b c d e]

>> b/1
== a

>> b/0
== none

What we need to worry about is clarity of how each series type behaves 
with the series functions (as uniformly as possible) and fixing the 
bugs for AT on blocks and PICK on strings.

Rebolek - but that is weird, isn't it? So b/-1 will return some word, 
while pick b -1 will return another?

Pekr, both kinds behave identically here.

Henrik - I am referring to Carl's proposed change to 'pick. Is it 
already implemented?

Yes, it's been like this for some time, I believe.

I will accept anything, as I hope Carl, BrianH etc. are very clever 
guys :-) I would just like things to be consistent. So when blog 
introduced some change, I would like to know also how functions like 
index? etc will behave ...

Pekr, [pick b 1] behaviour is not changed:

>> b: [a b c d e]
== [a b c d e]
>> b: skip b 3
== [d e]
>> b/0
== c
>> pick b 0
== c
>> b/1
== d
>> pick b 1
== d
>> b/-1
== b
>> pick b -1
== b

You are right, those functionalities behave consistently. I probably 
need some "rebol philosophy" explanation for such stuff. Why e.g. 
head is at first series element, and why tail occupies one past last 
series element, etc.

the change is that -1 from R2 is now 0. This is logical imo.

Rebolek - the thing is, that with REBOL, there is no 0th position.

But there is in math.

the indexes in R2 were ...-3,-2,-1,1,2,3... now it's -3,-2,-,1,0,1,2,3

When zero is added, the math for calculating offsets becomes simpler. 
Less code.

(but this is not zero-based indexing. it's not the same thing.)

I have to think and come up with example, when you use index? something, 
to get your position, I think that then the change shifts the calculation 
in such a case...

Exactly, Henrik.

Pekr, I don't know if it makes a difference, because INDEX? seems 
to be used only on positive values. Can INDEX? return negative values?

From what I see here, it can't, so it won't make a difference.

I remember, in the past, to use index? heavily. But back then something 
like blk/:value was not possible. Can't find any example or use case 
where it could fail ... so it might mean, that current behaviour 
will not harm any code ...

btw - one question - in above Rebolek's example - why when we reassing 
(reference) a block ('b in his example), index? refers to original 
block, whereas functions like 'length? behave locally to new referenced 
block? Just a question :-)

... is it just because it is usefull this way, even if not consistent?

'b is a block! type, so no excuse here that it just "points to original 
block at certain position" applies here :-)

It's perfectly consistent and useful for subblocks. If INDEX? was 
local to the block in use, a lot of things wouldn't be possible.

You would not be able to recall the position of the subblock. You 
would have to recalculate it every time.

If you want index to be zero, copy the block.

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.

Indexes are calculated by adding the base to the offset. The new 
behavior for PICK and POKE makes that consistent, though AT should 
be fixed as well as it is the only index-based native left (unless 
I've forgotten something). I've added bug tickets for all of this.

OK, thanks for explanation.

Personally I prefer 0-based indexing since it's more useful and less 
confusing, but we are stuck with 1-based.

Is there a way to control/stop a task by the calling process or shall 
the called task check a semaphore set by the calling process?

In R3? Tasks don't really work yet, and we may be changing the model. 
Aside from that, I don't know.

then I hope the final implementation will get something like freeze 
and kill

Tasks are really up in the air, especially since threads are being 
considered to be a bad model nowadays in the multitasking community. 
It would be good for REBOL to start with a good model now, before 
it becomes too late to change later. Maybe green processes like Erlang 
:)

whatever model gets chosen, some control would be good.

erlangs concurrency model, hot code loading, easy process communication, 
robust message passing 

and a nice database (let's call it rebnesia)...all ported to our 
fabulous rebol.
...when did you said you are ready with this brian? :-))