freenode/lisp - IRC Chatlog

21:53:59 thijso I don't fully understand what you mean White_Flame

21:54:18 thijso Have a separate hashtable mapping the "string keys" to something else, is that what you mean?

21:54:58 pjb Yes.

21:55:21 White_Flame yes, map "foo" => "foo", in a #'EQUAL hashtable. Then when you do (gethash "foo" *table*), it'll return the exact same "foo" string instance, which can be then eq compared in a table, without converting it to a symbol

21:55:23 Xach thijso: you could have a table that maps strings to integer IDs or something.

21:55:31 Xach Or that.

21:55:36 no-defun-allowed Does anyone use tries in intern tables?

21:55:49 pjb That said, it all depends on the speed of the hash function, which should be O(1) fast anyways. So using an equal hash table should not be significantly slower than using an eq hash table.

21:56:34 White_Flame even if it's O(1), its constant time can be much slower than an eq compare

21:56:53 White_Flame again, it all depends on where you want the cpu to spend time, if this is an optimization issue

21:57:15 White_Flame and depending on what you're doing, it might be advantageous to keep the data as a string

21:58:39 thijso ah

21:58:53 thijso uhm, not an optimization issue, no

21:58:57 thijso not yet, at least ;)

22:00:01 thijso I'll have to look into that map "foo" => "foo" trick later, because it's late here and I'm getting a 'does-not-compute' error in my head atm... ;)

22:00:22 thijso thanks for the suggestions, though, I'll be sure to check 'm out

22:28:12 White_Flame thijso: there may be many string instances of "foo". however, the one that is the value in that hashtable is the "canonical" one. by always looking up your string in that hashtable and only using the value from there (lazily adding to it if the key isn't found), you basically intern your strings to EQ-able instances

22:28:36 White_Flame (just for understanding/reference)

2:52:27 X-Scale` ** NICK X-Scale