Here is my very subtle mold change applied to Gabriele's script:
associate: func [block [block!] key value] [
head change/only any [
find/tail block mold key
insert tail block mold key
] reduce [value]
]
associate?: func [block [block!] key] [
all [key: select block mold key first mold key]
]
I cannot find any bugs, someone else want to try?
--Ryan
[EMAIL PROTECTED] wrote:
> Keith and Pek made me realize the obvious. The main problem with select is we
> need to use it with two differrent datatypes. Thus so, we can force the key to
> string and wrap the data with a block. I believe if we convert the string with
> mold we save data type integrity. I think this solves all problems with using
> select.
>
> --Ryan
>
> [EMAIL PROTECTED] wrote:
>
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, September 18, 2000 4:35 PM
> > Subject: [REBOL] Associative Data Store Re:(2)
> >
> > > I'm probably going to get beaten up for this :), but if my question is
> > > totally absurd, please excuse my ignorance...
> > >
> > > You seem to put a lot of emphasis on being able to use block!s as keys. Is
> > > this really necessary or desired?
> > >
> > > It seems like an implementation would be easier and/or more efficient if
> > we
> > > didn't have to worry about that case. Same for logic! values :)
> > >
> > > Many other languages get by with just strings for keys, why do we have to
> > be
> > > able to use every Rebol data type as a key?
> >
> > That's true. Even XBase systems work that way. In real - what about any
> > entry form fiels? They are all strings ... and if not, you can convert to
> > string first :-)
> >
> > -pekr-
> >
> > >
> > > Keith
> > >
> > > ----- Original Message -----
> > > From: <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Monday, September 18, 2000 7:47 AM
> > > Subject: [REBOL] Associative Data Store Re:
> > >
> > >
> > > > 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]
> > >
>
> --
>
> Ryan Cole
> Programmer Analyst
> www.iesco-dms.com
> 707-468-5400
>
> The problem of language here are really serious.
> We wish to speak in some way about the structure
> of the atoms . . . But we cannot speak about atoms
> in ordinary language. -W. Heisenberg
