freenode/#lisp - IRC Chatlog
Search
16:57:14
beach
elderK: It is a generic function with a method that specializes on the binary-type class.
16:58:07
beach
When it says :reader sizeof, it is essentially the same as a method that calls slot-value on the slot. But it is typically much faster than such a method.
16:58:37
beach
So (defmethod sizeof ((object binary-type)) (slot-value object 'sizeof)) or something like that.
17:01:08
beach
elderK: In the past, they were wrong because they would fail in situations such as when the object did not exist, or when there were multiple occurrences.
17:01:08
elderK
At Uni, I saw a lot of people fail when the "sequence" they were binary searching had an even number of elements.
17:01:47
beach
elderK: Not so much now. Now they just fail because they start by testing for equality, which makes them take 50% longer than they should.
17:02:16
elderK
It would be like hashing somewhere in an open-addressed hash table and not checking like, that the thing you've hit is actually what you want.
17:02:43
trittweiler
You shouldn't test for equality at all. That's by definition only true once. It's the uncommon case :)
17:02:50
beach
And if you start by checking for that, you increase the execution time by 50% on the average.
17:04:19
elderK
beach: I'd still like to learn from it all the same, just to avoid making the same mistakes when I work in other languages.
17:06:24
elderK
trittweiler: I'd like to hear about how you deal with say, chained hash tables. I guess you could have a secondary hash and check those as you traverse the "chain" for some primary hash
17:07:41
elderK
beach: I'd agree with you. I've been surprised by how often I've seen implementations of say, search trees, that perform comaprisons more than necessary.
17:07:54
elderK
although I guess that's a different kettle of fish, I still feel it should be avoided at all costs.
17:07:56
trittweiler
The other thing is that binary search should not be a binary thing, it should return the index of the item if found, or the index where the item would have to go if one wants it to be inserted. Of course in CL, there are multiple return values, so it easy and convenient to do that.
17:10:19
elderK
beach: I believe it was you, a few days ago, that suggested reading docstrings from files?
17:11:02
elderK
I was wondering about that. Would you like, read-string or whatever at read time? (:documentation #.(read-doc-r-something)) ?
17:12:42
elderK
beach: Any chance you can link me to an example of like, the approach you recommend?
17:13:15
elderK
I imagine the project has a file somewhere that contains mappings of symbol -> documentation, and some other file that processes that and attaches the documentation to those symbols?
17:13:57
elderK
I've been kind of unsure how to best document my stuff, you see. So, seeing "good examples" would be really useful.
17:14:21
beach
https://github.com/robert-strandh/SICL/blob/master/Code/Sequences/Common/docstrings-en.lisp
17:15:05
beach
elderK: It would be the Common Lisp compiler and ASDF that process those. Nothing special here.
17:17:13
jcowan
beach: I understand placing the CL: docstrings outside, but do you extend this to all function-likes?
17:17:13
beach
Notice how you can have very complete documentation strings without polluting the source code with irrelevant information.
17:17:35
elderK
beach: I particularly like that aspect of this. Are those parameters only defined in the doc lisp?
17:19:31
jcowan
Okay, but what's the logic for making them external? What encouragement is there to keep them up to date as things change? (The CL spec doesn't change, that's why I see it as a special case.) I can barely keep comments *with* the code up to date.
17:20:21
elderK
jcowan: I guess it's no different than having say, "Doxygen docs" separate from C code. You have to maintain them yourself.
17:20:49
beach
jcowan: Documentation strings are for the protocol objects. Those had better not change.
17:21:19
elderK
beach: So, you don't bother documenting say, internal things? Helper functions and whatnot?
17:22:30
elderK
Like, each line starts at the same offset. Most docs I've seen are indented some on the first, and the rest are all flush.
17:23:11
jcowan
"It is not sufficient merely to prove a program correct; you have to test it too." This shows what a farce proof is.
17:23:37
jcowan
"Almost all theorems are correct, but almost all proofs have bugs." --Paul Pedersen, mathematician turned programmer
17:24:39
elderK
It just seemed like it was forwarding every to format, but always resulting in a string
17:25:30
elderK
:) for some reason, I thought docstrings were like, not evaluated. Like, that they had to be specified as strings, rather than the result of a function.
17:25:30
beach
This https://github.com/robert-strandh/SICL/blob/master/Code/CLOS/compute-discriminating-function-support.lisp is how it looks when it is meant for the maintainer.
17:26:54
jcowan
Yes, if you only use docstrings for externally visible things, I understand your reasoning. But the fact is that protocols, unless dictated by standards or arms-length relationships, change all the time too. When $EMPLOYER announces a public API this year or next, it'll have to be carefully stabilized and versioned, but the various internal APIs will undoubtedly go on changing as $PRODUCT grows new features.
17:27:26
elderK
Those *...* parameters are /defining/ the docstrings. Nto being documented themselves.
17:28:39
beach
jcowan: I am also surprised to see that, because APIs are not stable, that implies that every internal function must have a docstring.
17:29:06
elderK
~_~ Then again, most APIs I've had the misfortunate of working with in some way, have been horribly designed. Almost schizophrenic.
17:29:31
elderK
Like, professionally. I like to think of the APIs of my own personal things are much nicer :) But you know, YMMV.
17:30:12
jackdaniel
i.e some think about docstrings as a short contextual information serving a purpose of a reminder
17:30:27
beach
Either way, *I* don't plan to break my protocols, so *I* don't see the problem with detached documentation strings. If you plan on breaking your protocols, sure, put short docstrings in the code.
17:32:30
elderK
jackdaniel: I guess having that as a docstring, rather than say, a comment, is more useful since you could find that stuff in apropos or something?
17:33:35
jackdaniel
that may be how people think, yes. I don't have strong opinions about the topic except that cl's documentation abstraction is not well suited for writing software documentation
17:33:42
_death
it's also possible for something to change in a non-breaking way, and the documentation still has to be updated.. I like to see a docstring when I go to a definition
17:34:19
elderK
_death: Is there somewhere I can like, refer to, to learn about how... well, to ensure that the docstring appears properly aligned when viewed?
17:34:52
elderK
I like to have my text all indented to the same level, for... personal reasons, I guess. But I'm not sure how this would appear when someone calls documentation, or say, hovers over it in SLIME
17:37:54
jcowan
Doing such things is inevitable in an environment where not everything can be planned, much less implemented, ahead of time, and actual customers have put their money where their mouth is and have a right to expect something rather than being told "Wait a few years and you can have it perfect." They need it now, not perfect, with a believable promise of improvement.
17:38:01
_death
elderK: the thing is that docstrings appear differently in different contexts.. for example they may appear one way if you use the DOCUMENTATION function to retrieve them, and another way if you stumble upon them in the source.. personally I think a good format is a short paragraph or a line describing the function, perhaps followed by more paragraphs detailing things.. Emacs's Lisp code has lots of nice docstrings and makes for good
17:38:18
jcowan
(This is about design, not implementation; of course that is always going to have bugs.)
17:41:22
elderK
I was wondering if there was some convention I could follow wrt say, writing the documentation or directives, that would ensure it would be properly... uh, rendered, in the right places.
17:41:35
_death
elderK: since this makes the first paragraph "special", it's easier to live with the different indentation
17:42:05
elderK
_death: Right, so that explains the usual indent of the first line, then the rest flush.
17:42:34
elderK
Still, I've studied code that has say, 16+ lines in a docstring, sometimes more. It gets in the way.
17:42:53
elderK
although I imagine that might be a limitation of slimv - maybe emacs folds the documentation so it isn't so intrusive when viewing code.
17:43:17
_death
elderK: https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html#Documentation-Tips many of those apply to CL docstrings as well
17:44:40
jcowan
Well, understanding short-form DMC was easy, but long-form (aka RUN) DMC is another matter.
17:47:31
pjb
I'm not against storing the docstrings in a separate file. As long as you have an emacs command to display it automatically near the function you're editing, and to let you edit it along easily.
17:48:18
pjb
As much as I wouldn't be against an emacs mode that would choose itself where to store toplevel forms, without you having to C-x C-f a specific file.
17:49:33
elderK
beach: I'm having trouble finding information for ~@. Everything I can find is like, ~@ followed by some suffix.
17:50:23
makomo
elderK: find the CLHS format function and then take a look at all of the various format specifiers or w/e they're called
17:54:47
pjb
elderK: : and @ are optional flags for ~ specifiers. They are not specifiers themselves.
17:56:50
elderK
jibanes: I figure that depends on whether your implementation supports Unicode source.
17:57:04
pjb
(map 'list 'char-code "¯1↑1 2 3 4 5") #| --> (175 49 8593 49 32 50 32 51 32 52 32 53) |#
18:02:51
pjb
A lot of bugs or problems that occur in other languages, (and that let people get real actual PhD and to build whole cottage industries earning hundreds of millions each year) just cannot happen in lisp. This is why we're poor and with so few research grants.
18:04:26
jcowan
The existence of bignums in Lisp is irrelevant, because binary search happens within an array, and the array size limit is always a fixnum.
18:06:12
pjb
jcowan: depends on whether (<= (* 2 array-total-size-limit) most-positive-fixnum) or not.
18:07:21
jcowan
No, because bignum arithmetic (no overflow) plus array bounds checking will give you an error instead of the wrong answer.
18:08:07
pjb
The problem is that with modular arithmetic, of when no overflow is detected, they get the wrong index.
20:00:41
aeth
elderK, beach: If you need to work with types instead of classes, use https://github.com/markcox80/specialization-store/
20:04:04
aeth
And I think it is slower, except when inline, which can only happen when the type is declared (since CLtL2 doesn't expose the type inference, only the type declarations)
20:57:29
aeth
Working with types probably means numbers or arrays, e.g. (simple-array single-float (3)) or (integer 0 42)
23:34:38
jcowan
It's interesting in that you don't have full control of which method is chosen, only that it will work (and therefore all methods must produce the same results, just by different means)
2:50:52
jcowan
Is the pattern of multiple values that SUBTYPEP uses (first value is the value, second value is a boolean indicating its validity) a common one in CL code?
2:53:45
Bike
i think alexandria:type= uses the same return values, but that's for basically the same thing.
3:25:41
fouric
does anyone know of a lisp reader that preserves the locations of the forms that were read in in the file?
3:26:22
fouric
that is, when i invoke said hypothetical READ, it returns not only the results of normal READ but also line numbers and character indices/columns of where each atom/list was found
3:34:28
Bike
beach's reader has stuff for source tracking https://github.com/robert-strandh/Eclector/