Re: fastest data structure for a hash-like lookup

[Florian von Savigny]

"Stefan Monnier" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> What do the keys look like ?  Can you choose them freely ?

They are strings, more precisely, attribute values (ID tokens) taken
from SGML instances.

> In elisp, it seems you could use a hash table of lisp lists,
> vectors, or structures.  See `defstruct' in the CL manual for
> structure.

CL means "common lisp"?

> See `make-hash-table' in the elisp manual.

That seems to be Emacs 21, which I'm trying to do without.

> You mean it would be built once and for all and then stay constant.

Yes, the code will even written by another program and imported by
emacs via load-file.

> > Sorry I wasn't able to find any useful documentation (the manual is as
> > terse as ever).
> 
> Which manual, what did you look for in it, what did you expect to find
> and what did you find instead ?

I tried to find advice on nested data structures in the chapters about
Lisp data types, lists, and sequences, arrays and vectors. There is an
example of a nested alist under copy-alist, but I tried to find the
fastest such structure (and I doubted an alist was fast, since "keys"
are not unique there). There was no hint in the section about vectors
whether you could use them in such a way. After having played with
Kevin's kind proposal, I realise chapter 7 about symbols is very
relevant, but that's not where I thought to find anything.

I'm not criticizing the manual in saying it is terse (condensed, more
precisely). That makes it very clear when you try to find some detail
you've forgotten. What I sometimes miss, though, is something with a
"cookbook" approach: "I want to XY, how do I ...".

It is hard for me to say what I "found instead", since I haven't tried
to read in depth what apparently wouldn't help me further. It seems
entirely possible to me if I knew more about the BASIC NOTIONS of
Elisp, it would have been quite obvious that yes of course, why not,
structure X and structure Y can be combined, thus, sections that
seemed without a clue now would have been very helpful then. I suppose
I'm not a serious programmer in this sense; I only try to learn things
as far as I need them to produce something I can use (in other words,
I'm the type who uses Perl...). Imitating also saves a lot of time
compared to trying out.

I don't know whether that answers your questions adequately.


-- 


Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.