freenode/lisp - IRC Chatlog
Search
16:50:08
Xach
scymtym_: Ok. I think I will think that it is superfluous for now, but am open to persuasion otherwise.
16:51:01
Xach
My thinking today is that package-local nicknames must be implemented without adding any new packages or functions, only new arguments and return values to standard functions, if they are to be really useful. No compatibility layers.
16:51:33
Xach
package-local nicknames are in a good place among theoretical extensions to be done that way
16:52:01
vtomole
How big do your function definitions need to be before you need to break it into helper functions? Is there a general rule or is it up to the programmer?
16:52:35
beach
vtomole: A good heuristic is that the function must fit on a screen so that it can be read entirely by the maintainer.
16:53:28
scymtym_
Xach: i assume the overwhelming majority of cases would only involve the :LOCAL-NICKNAMES option to DEFPACKAGE
16:53:32
TMA
vtomole: other than that, if you find yourself asking 'shall I split this?' you probably should
16:53:41
schweers
I can’t help but wonder why it is so often brought up with lisp. This should probably be done in lesser languages too.
16:54:13
Xach
scymtym_: but that must also carry over into make-package, find-package, rename-package, and package-nicknames.
16:54:57
vtomole
https://github.com/robert-strandh/SICL/blob/master/Code/Reader/Fast/read.lisp read-upcase-downcase-preserve-decimal is huge here. I know there are always exceptions.
16:55:35
scymtym_
Xach: of course, but wouldn't those mostly change behavior without changing signatures?
16:58:15
scymtym_
Xach: oh, are you suggesting all information (e.g. the local nicknames established by a package) should be available without adding new functions?
16:58:37
Xach
one possibility: make-package needs :local-nicknames, find-package needs :global as a new argument and a new secondary value indicating local vs global, rename-package needs a second optional value, and package-nicknames needs a :local argument
16:59:35
beach
vtomole: In this particular case, I only recently decided that I wasn't going to pursue this direction.
17:26:40
sigjuice
I have several versions of alexandria in ~/quicklisp/dists/quicklisp/software from continued use of (ql:update-dist "quicklisp"). How does quicklisp know which one to use?
17:27:08
Xach
sigjuice: you can remove the old copies with (ql-dist:clean (ql-dist:dist "quicklisp"))
23:10:13
Shinmera
My slide show app is coming along. https://www.youtube.com/watch?v=bB0BlN8ORiA&feature=youtu.be
23:25:29
hjudt
are there any best practices naming accessors? if i have a class "box" with a slot "id", should i call the accessor box-id or simply id? is there any advantage doing the former?
23:31:39
Xach
hjudt: I find it useful to think of the protocol of generic functions first, and then use defclass to fill in the easy blanks of specific methods. in that context it doesn't make sense to name the generic functions with the class name (usually).
0:24:23
didi
Wonder: Why isn't the syntax of `let' the same of `setf'? i.e. (let (a a-value b b-value) ...)
0:26:11
fiddlerwoaroof
didi: clpjure does that, it's a bit annoying because it's more difficult to delete a binding/value pair
0:29:09
fiddlerwoaroof
I have actually experimented with writing a wrapper macro for setf that looks like (setf* (a a-value) (b b-value))
0:31:09
Bike
i don't think there's much particular reason either way. of course, if you do write a let like that it's short for ((a nil) (a-value nil) (b nil) (b-value nil))
0:34:08
fiddlerwoaroof
didi: it's nice, but I'm always hesitant to introduce new things for such a trivial reason
0:50:49
Zhivago
I think the savings with setf are minimal -- with let it makes more sense since it would otherwise introduce one scope per variable.