Here's what happened when I tried it:
>> blk: []
== []
>> Associate blk [2 3] 5
== [[2 3] [5]]
>> Associate? blk [2 3]
== none
Beg pardon? Also...
>> Associate blk 5 7
== [[2 3] [5] 5 [7]]
>> Associate blk [5] 9
== [[2 3] [5] 5 [9]]
>> Associate? blk 5
== 9
>> Associate? blk [5]
== 9
Hmmm... Can't distinguish 5 from [5] ??
>> Associate? blk reduce [2 3]
== none
>> Associate? blk reduce [[2 3]]
== 5
Aha! Unlike all other data types, an extra [] wrapper is require
for block! -type keys? Well, let's check to see if the old
merged-key/value-space bug is still present.
>> Associate? blk reduce [[5]]
** Script Error: first expected series argument of type: series
pair event money date object port time tuple any-function
library struct event.
** Where: all [
Value: select Block Key
first Value
]
So I can't even check to see if [[5]] (or [5]???) might have been
legitimately used as a key?
This version still uses find and therefore still "inherits" the
buggy behavior when block! data are used as keys.
-jn-
[EMAIL PROTECTED] wrote:
>
> Here's an implementation for an Associative Data Store (ADS) that uses only
> two functions, doesn't require an object per ADS and can use any Rebol value
> as a key. Comment invited. Thanks to Gabriele for showing how to shorten the
> 'Associate? function.
>
[code snipped]
