libera/commonlisp - IRC Chatlog
Search
11:36:06
cpli
if i have to efficiently convert between syms and numeric values, is an alist a good idea?
11:37:06
cpli
^ this snippet currently creates one large case statement which sbcl nicely compiles into a lut
11:48:47
pjb
cpli: I use (ecase expr (#.+foo+ +foo+) …) ; in both cases, you need to wrap the the defconstant in eval-when :compile-toplevel (or compile and load them separately first).
11:50:51
cpli
pjb as in you create a list of 2-element lists as a toplevel compile-time constant and then use a macro?
11:54:04
pjb
You may use a macro. In that case, you can generate both the defconstant and the functions to convert using the values directly. See for example: https://gitlab.com/com-informatimago/com-informatimago/-/blob/master/common-lisp/cesarum/utility.lisp#L389
12:01:29
beach
cpli: It is recommended to use '() to initialize the lexical variable to the empty list.
12:02:25
beach
cpli: And the use of KEY as a Boolean is a violation of the rules suggested on page 13 of the LUV slides.
12:05:53
beach
cpli: And for a large number of values, I might have preferred a hash table. For a small number of values, it doesn't matter much whether you use a CASE form (not a "statement") or alist.
12:07:43
jackdaniel
on the other hand the implementation may generate better optimized code form a CASE form compared to using a hash table
12:08:26
jackdaniel
(in fact I think that sbcl indeed does something special when cases are numbers)
12:08:46
splittist
cpli: you are receiving symbols and run time, and need to turn them into integers?
12:08:58
beach
Sure, you may want to program specifically for one implementation if you really need top performance.
12:11:22
cpli
it isn't, i'm not some crazy hacker. nullpointer (the paste service) just sniffs maim badly
12:12:15
cpli
jackdaniel: they're both. but the user facing code shouldn't have to deal with windows/macos(karabiner)/linux(evdev/libinput) keycodes simulatiously
12:12:26
beach
OK, I just read "if i have to efficiently convert between syms and numeric values, is an alist a good idea?".
12:14:54
jackdaniel
in any case (ha!) CASE gives more opportunities for the compiler for optimizations than a hash table. in the worst case the implementation may implement it with a hash table
12:15:20
cpli
i have a keybind that POSTs my clipboard onto 0x0.st and replaces the clipboard contents with the url, so it's my goto
12:16:55
jackdaniel
hayley: yeah, it could be that the compiler will do worse than what it could do with the information
12:17:22
jackdaniel
but if we are not relying on good behavior of the implementation, are we going to rely on its fuckups and avoid better suited (more specific) language operators?
12:17:33
hayley
That does not negate my statement; a sufficiently unsmart compiler could well generate a sequence of tests.
12:18:04
cpli
beach, for now i don't mind being that implementation dependent. my posix utils package has specific cffi fallbacks for when sb-posix is unavailable
12:18:53
cpli
i don't think specific assembly optimizations that may or may not be performed by my impl should stop me from writing the product first
12:19:00
hayley
An actual hash table is easier to implement than transforming branches into a lookup table into a compiler, I would guess. Have yet to implement the latter :)
12:21:42
splittist
cpli: then why not deal with it at compile-time? Instead of :a have a reader-macro #!a that converts to the integer. Then it can take as long as you like.
12:25:32
cpli
splittist: the integers are unique on different platforms, i just deal with that by #+windows?
12:29:16
cpli
splittist: would'ya recommend i swallow the additional dependency and use uiop instead of features?