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


Reply via email to