freenode/#lisp - IRC Chatlog
Search
21:54:18
thijso
Have a separate hashtable mapping the "string keys" to something else, is that what you mean?
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: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: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
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: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
9:07:01
thijso
If I do (ensure-directories-exist "~/.storage/3") and don't get an error, I should reasonably expect that directory to exist afterwards, right? Is there anything I'm missing? Or is ECL's implementation of that function broken? I really can't imagine that, but on the surface it does look like it...
9:07:40
thijso
The really strange thing is, that creating "~/.storage" the same way, just before, *does* work
9:09:03
thijso
Hhmmm, and if I do the full path without just .storage before, it only creates .storage, not the full one