[Rd] dict package: dictionary data structure for R

[Seth Falcon]

Duncan Temple Lang <duncan at wald.ucdavis.edu> writes:
> The HashFunc typedef in hashfuncs.h would be more flexible  if it
> took an additional argument of type void * to allow for user
> defined data.  Alternatively, it might take the hash table
> object itself.  The function might want to do some
> updating of the table itself, or look at some table (e.g. for perfect
> hashing).  And if we had a place to provide additional information, it
> is easy to allow the hash function object to be an R function.

Worth considering.  I don't think perfect hashing is in scope here,
but would need to give it more thought -- seems to me that perfect
hashing would be better served by something separate.

> Also, you are using a "global" table of hash functions
> (i.e. Dict_HashFunctions) and looking up the C routine using
> GET_HASHFUN
> which is tied to the integer indexing for this global table.
> Why not use the C routines directly from R, i.e. using
> getNativeSymbolInfo and pass this from R to the newly created
> dict.  This avoids the lookup, the global table and makes things
> extensible with routines in packages and simply extends to allowing
> R functions to be passed instead of C routines.
> It also removes the need to synchronize the labeling system in
> R and in C, i.e. that 0L corresponds to PJW. The reliance on
> synchronized names rather than direct handles is unnecessary
> although widely used in S/R code.

Why not?  Only because I didn't think of it ;-)

> I'm more than happy to give some code to illustrate what I mean
> more precisely if you'd like it.

Sure.  At the same time, I'm a bit hesitant to invest further in dict
until I get a sense of whether or not it might actually be useful to
people.  It's main use may turn out to be for investigating hash
functions behavior and for a test tool it may be sufficient as-is.

+ seth

-- 
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org