freenode/#lisp - IRC Chatlog
Search
19:39:32
aeth
ebrasca: the problem with returning nil is that it could be a legitimate value, especially false or the empty list. There are afaik four common options here: raise a condition (or whatever the exact terminology is), return two values with the second value also being nil, use a keyword (which only works if it's not arbitrary data like a hash-table value), or return a (usually user-provided) default value
19:42:26
aeth
You can also do fancier things like return (values) as in no-value but that's normally treated as nil so it would require fancy handling. Afaik, only multiple-value-call and multiple-value-list would be able to detect (values) without just automatically replacing it with nil.
19:44:55
aeth
What's particularly interesting in some APIs is combining option #4 with option #1, i.e. having an error unless a default value is provided
0:33:27
edgar-rft
Common Lisp is full of overloaded functions, you don't need to be afraid to add your own :-)
0:40:18
aeth
gabbiel: You have other options, e.g. https://github.com/markcox80/specialization-store/ but that will come at a performance cost without type declarations
0:43:12
gabbiel
aeth: yeah I was thinking, if symbols weren't restricted to one function, one could define many functions for a symbol, but that'd require declaration of types like in methods
0:44:45
aeth
well, no, if the library is robust enough, then you'd get runtime dispatch or compile-time dispatch, but the compile-time dispatch would be (1) only on certain implementations that have the proper extensions and (2) only if you have type declarations in your code because the type inference isn't exposed even to the extensions from point #1
0:51:00
aeth
gabbiel: Yes, I was talking about in the caller, not in the definition. The definition would need types.
0:52:32
aeth
gabbiel: And there's nothing (other than pulling in yet another dependency) stopping a defun wrapper from using something like defspecialization as a backend when requested.
3:27:46
asarch
One very very very stupid question: If I compile the newest release of SBCL (1.5.5) with an old version (1.4.8) will this resulting binary differ from the one compiled with the newest release (1.5.5 with the resulting binary from 1.4.8)?
3:30:18
beach
asarch: The result ought to be the same. If it is not, then that might indicate a problem.
3:35:49
asarch
cmp ./src/runtime/sbcl $( which sbcl ): ./src/runtime/sbcl /usr/local/bin/sbcl differ: char 307242, line 681
3:51:46
akoana
asarch: beach is right, the sbcl binary contains a build timestamp like hostname-user-yyyy-mm-dd-HH-MM-SS
3:52:42
akoana
asarch: may be you can see it with grep -a -o -w yourhostname....................... ./src/runtime/sbcl
4:07:13
akoana
ACTION suspects that could be done in a few lines of Common Lisp, display n bytes of both files starting from the difference
4:07:19
asarch
OpenBSD's cmp doesn't support the -b flag, however, this its output (every ; represents a newline): 307242 61 62; 307244 60 61; 307248 62 70
4:08:22
asarch
$( which sbcl ): /usr/local/bin/sbcl <- This was the 1.5.5 compiled with the old 1.4.8 version without '--fancy'
6:10:02
akoana
beach: now I've done a quick and dirty (and bad style but working) cmp replacement in Common Lisp :)
6:18:22
edgar-rft
I think we did a little mistake. The sbcl binay is only the loader, while the Lisp image on my machine is stored under /usr/lib/sbcl/sbcl.core. IMO it would make much more sense to cmp(1) the Lisp images instead of the loader.
6:53:35
akoana
edgar-rft: good point, seems sbcl-core also has that build timestamp, beginning at byte 32