Re: Dictionary, hashing limitations
- From: Jonah Thomas <j2thomas@xxxxxxxxxx>
- Date: Tue, 22 May 2007 00:19:19 -0400
Bruce McFarling <agila61@xxxxxxxxxxxx> wrote:
Jonah Thomas <j2tho...@xxxxxxxxxx> wrote:
If it works for 0-255 then you can provide users with associative
arrays that allow absolutely anything for a key (with only the
length limitation). If it works for 33-126 then it still allows
any text string < 32 characters, which isn't shabby.
Of course, if it works for text strings up to 31 characters, then it
works for unsigned uunecoded natural numbers of up to 155 bits.
Sure, that works. But it's an extra step, and it isn't that hard to
build your own binary tree or whatever and solve your problem all on
your own.
And if you want to port your program then you'd like to have the
low-level dictionary words that aren't currently standardised, and you
don't know what kind of associative array you'll get -- you might port
it to a system where it's just a linked list, or it might use a hashing
algorithm that your particular keys work badly with. If a linked list is
acceptable you can make your own linked list easily without jumping
through hoops to use the system's dictionary.
And of course lots of target compilers won't have a dictionary on the
target at all.
I like the idea of making the system internals maximally useful for
applications, and at some point that approach breaks. I'm curious where
that point comes for the dictionary. Clearly you can do anything you
want provided you design your values as Forth words and your keys as
Forth names.
There may not be much value in allowing associative arrays whose values
don't get executed -- to some extent constants, variables, values,
deferred words, create-does> words etc are objects. You usually don't
have to know what type they are; you can execute them and their own code
knows what to do. What you gain from bypassing this little bit of
overhead may not be worth it. But then again, the dictionary does
something clean and simple -- you give it a key and a value and it saves
them. Later you give it the key and it gives you the value. Why should
there be any unnecessary limitations on that? If the key is the contents
of any address/length pair, and the value is a bit-pattern (which might
be an execution token or an address but doesn't have to be), what harm
is done? Providing your particular hashing algorithm allows it.
.
- Follow-Ups:
- Re: Dictionary, hashing limitations
- From: Elizabeth D Rather
- Re: Dictionary, hashing limitations
- References:
- Dictionary, hashing limitations
- From: Jonah Thomas
- Re: Dictionary, hashing limitations
- From: Bruce McFarling
- Dictionary, hashing limitations
- Prev by Date: Re: Dictionary, hashing limitations
- Next by Date: Re: Dictionary, hashing limitations
- Previous by thread: Re: Dictionary, hashing limitations
- Next by thread: Re: Dictionary, hashing limitations
- Index(es):
Relevant Pages
|
Loading