On Mon, 04 Mar 2002 03:44:21 GMT, Dave Thomas <Dave / PragmaticProgrammer.com>
wrote:

>It kinda sounds like you're really dealing with symbols. Would #intern
>etc help at all?

Well, it's worth thinking about as all my data are immutable. But I think not,
as the very thing I'm trying to do is to slice 'MIjeffries' into 'MI' and
;'jeffries'. 
>
>  { :state => :MI, :name => :Jeffries }
>
>(where {} _are_ hash constructors).
>
>Then you could define your set operations across hash slices... (if I
>understand where you're going)

You had me going there for a minute with "hash slices". Hashes don't have slice
behavior ... do they? My tests indicate not.

But hashes pointing to slices ... hashED slices ... maybe that's what you mean.
Yes, that's part of what is going on inside this deal, certainly in this case:

We start with 'MIjeffries' which is nominally 0=>M 1=>I 2=>j and so on ...
after the first transform we get 0=>MI and 1=>jeffries, which is some kind of
slice combining deal, and then the second just renames the slice keys state=>MI
and name=>jeffries.

I woke up this morning with a similar idea. Since, as we all know, the set is
independent of how its membership condition is expressed, I can do the whole
thing by hosing the scopes and ignoring the elements, just reslicing them.

This leaves me with a problem, which is recognizing that 
{ { M[0],I[1] }[state], { j[0] e[1],f[2],f[3],r[4],i[5],e[6],s[7] }[name] }
equals { 'MI'[state], 'jeffries'[name] } which it "obviously" does, but the
computer doesn't seem to notice. ;->

So your comment reinforces my early morning idea, and if hashes really do have
slices, please expand. Upon the idea, that is.

Thanks,


Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.