Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Associative Data Store Re:(4)

From: ryanc:iesco-dms at: 18-Sep-2000 10:35

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 [petr--krenzelok--trz--cz] wrote:
> ----- Original Message ----- > From: <[rebol--keithdevens--com]> > To: <[list--rebol--com]> > 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: <[joel--neely--fedex--com]> > > To: <[list--rebol--com]> > > 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- > > > > > > [Al--Bri--xtra--co--nz] 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