World: r3wp

It only becomes duplicate values if the value is not a reference 
type (numbers, characters, etc.).

Brian: Good to know.

Pavel, yes, the homogenous type is the only main difference relative 
to blocks. Only use vectors if you need that, else use blocks.

So, if I understand correctly, map! offers a superset of hash! features 
(without giving up anything)?

Not bad if the performance would be good (especially for quite large 
pointer table to database file), save in size was already mentioned

You give up position and persistent ordering, and in theory you also 
give up duplicate keys though there is a bug ticket about that.

You also have to conform to the key/value pattern. Map! is more comparable 
to object! nowadays.

Doc question arise when large insert into large table comes, in hash 
inserting is the slower the bigger is table (maybe even nonlinear)

It can be key/[block of values] though.

We are extending support of many of the functions that people traditionally 
associated with series to objects and maps, without making them into 
series. So that means that APPEND works, but INSERT doesn't because 
of the position stuff.

For Map also limit about 500000 items was mentioned, it suggest an 
idea use Map in pagged manner. Ie for larger set use multiple Maps 
rather fixed size in the manner of cache.

Pavel: is map! any better in that case?

I have no exact comparison all mentioned is only ideas

SELECT works on object! and map! but FIND doesn't. PICK and POKE 
work, but they take keys rather than indexes. There are some (at 
this point undocumented) limits on what can be used as keys too (at 
least you can't use a block as a key in practice), but that may be 
a bug.

Lot of new exceptions to remember...

Brian Block as key would be good for reversed index IMO. Question 
if it would be usefull.

Well, in some cases to fix, but yes, lots of exceptions. The guideline 
is that maps and objects don't have position, but series do. So the 
position-dependent functions don't work but their non-position-dependent 
counterparts do. Ports don't work like series either, so there is 
another whole set of differences to remember.

Good point Pavel, how does map! handle the key/key case? (being able 
to exchange the role of key<=>value). Would it require to use two 
map! to being able to do fast lookups in both cases? So n-tuple stored 
=> n map! value to hash everything?

Pavel, the problem is that we can't hash complex structures (for 
now) so there is no advantage to using them as keys. I want a keys-of 
function though that returns a block of the keys that reference a 
value (by same? semantics for the value, perhaps).

The words-of function already returns *all* of the keys of a map!, 
just like it does for objects.

I dont want to use keys in this way (difficult keys) the opposite 
is true, keys should be simplest possible.

Well then you have no problem then :)

Doc I think so

But it is not necessary week point if the design of data would be 
good

Anyway it leads to multiple lookup when data is difficult

I agree, Doc, that sounds like a good plan. Map! storage and implementation 
is in theory more efficient than hash!, so having two of them shouldn't 
be a problem, as long as your wrapper functions keep track of the 
mirroring.

The only trick is that you remember that none means nothing, so don't 
bother with a none key. The theory of map! is either:

- Keys that are associated with none don't exist in the map!, so 
assigning none to a key makes it go away.

- All possible keys are in the map! but only the ones associated 
with something other than none are displayed.

There is no difference between these two theories in practice, and 
whether there is memory allocated for keys that you can't see is 
an implementation detail that is irrelevant to the use of map! (though 
there is usually not).

something related, in the past i made some tests to simulate hashs 
with integer keys in R2. I used a bitset as an index, mixed with 
block of blocks to store data.

my tests show that for 10000 records,  finding data is near as fast 
as with hashs. 
actually it's incomplete but you have the idea with this:

REBOL []
f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
] 

t: now/time/precise
loop 10000 bind [flag random 99999] f
print now/time/precise - t
t: now/time/precise
loop 10000 bind [flag? random 99999] f
print now/time/precise - t

Just a question. Is there a way to rappresent  Unicode Characters 
inside a string with an escape sequence ?

^(hex characters)

. The console may not render the character properly if the font doesn't 
support it though - it may look like a space.

Same as R2, but you can provide more hex characters.

Yes Pavel, that is the way it looks to me also regarding the vector.

Yeah, vector! doesn't work yet. There are a lot of tickets for vector!, 
all deferred. That to-block bug is not there, but not unexpected.

Brian, I think we need to address the lack of list in R3.  Maybe 
a list like handling of block data that still returns a block.

at the performance level of list.

I think that would be an excellent thing to address with a user-defined 
datatype.

People in general didn't use list!, because of the bugs and because 
block! was good enough for most uses. We haven't felt its lack for 
a year now. Most of the advantage of list! in regular code was handled 
by allowing insert and remove at the head of a block! to expand or 
contract the block, just like it does at the end, without a block 
copy. Just by making block! more efficient for inserts and removes, 
we have made list! even less necessary.

For that matter, you can make blocks even faster by getting rid of 
list!, just by enabling more optimizations.

The real advantage of list! wasn't the speed though, it was the alias 
persistancy. That was the source of the bugs in list! too.

I tested vector! extensively about one and half year ago. Not much 
changed, I think. The BIGGEST problem with vector! is that it's zero 
based.

Trust me, vector! has bigger problems than that right now. I expect 
that it will not end up 0-based though, even with all of the advantages 
that 0-based vectors give us. It is likely that we will instead have 
0-based versions of PICK and POKE that work on all series.

Brian, all the vector! tickets are mine, so I know very well about 
vector! problems :) I'm not sure about zero based PICK and POKE, 
I would probably prefer PICKZ and POKEZ, but I can get used to it.

Yes, those would be good names for the aformentioned 0-based versions 
of PICK and POKE. PICK0 and POKE0 have also been suggested as names, 
though I prefer *Z. They could be natives (or mezzanines?) that call 
PICK and POKE internally. I think the only reason we don't have them 
already is that PICK is an action!, and the naming disagreement.

Are blocks stored in memory as linked fragments?

no

How can inserts at the head and tail be done without moving the block, 
then?

you asked for blocks not for lists

Yes, Brian talks about blocks above

where ?, i don't think so

I´m not talking about links for each item, but for fragments determined 
during use