freenode/#lisp - IRC Chatlog
Search
22:10:28
Josh_2
pjb has already been through this with me when I have talked about making this kinda metaclass before
22:55:55
sveit
hello. does the maintainer/anyone familiar with the internals of the series package hang out here?
22:55:57
sveit
i have found several bugs that i would appreciate advice on how to begin attacking (as well i would love to discuss the package in general). i have also "fixed" a bug that seemed too trivial/actively introduced to have as simple a fix (deleting a line) as it did, and would like to know if i made an oversight before submitting.
23:03:12
sveit
well thanks for the update :) i am surprised, imo it is a great idea, and a great demonstration of something that could really only be done in lisp
23:03:39
sveit
if people have free time, writing non-trivial code and looking at the series macroexpansions/optimizations is pretty remarkable. except for the bugs :)
23:05:08
sveit
anyway, if anyone has looked at it before or knows of similar code and has general wisdom i'd like to hear it, since series is written in a somewhat haphazard way.
23:06:48
sveit
actually if it is abandoned i assume people have alternative libraries that they use to accomplish similar things?
23:55:44
fwoaroof[m]
I've also implemented clojure-style transducers for a kind of explicit stream-fusion approach
23:57:27
fwoaroof[m]
I like this better than series-style stream fusion, because it's not as dependent on "magic" compile-time transformations
23:58:59
sveit
the problem with loop is "reusability" and "composition"; it is kind of tricky/impossible to have some independent looping constructs that can be combined in a generator style. the idea of series is (imo) to provide this while having loop-style performance when the computation is actually built up
0:00:01
sveit
even the trivial idea of "loop from float F1 to float F2 with N samples" is irrating to write over and over again
0:01:30
fwoaroof[m]
You probably could fork series and put it on quicklisp with a new name, if you want to maintain it :)
0:02:40
fwoaroof[m]
Some LOOP implementations can be extended, but that's not specified in the standard
0:03:10
sveit
i know about iterate, but i think series is much more elegant and powerful (here the elegance is in the using, not the implementation :)). i probably will try to fork/maintain when life calms down a bit :) for now i just have my list of bugs.
0:05:07
fwoaroof[m]
SERIES relies on the ability to inspect declarations and do compile-time transforms, which I believe relies on either environment introspection or a code-walker
0:06:10
fwoaroof[m]
Transducers are pretty straight-forward to implement "in userspace" and are basically equivalent, from a composition/reusability perspective
0:06:33
fwoaroof[m]
https://github.com/fiddlerwoaroof/lisp-sandbox/blob/master/transduce.lisp#L152-L158
0:07:08
fwoaroof[m]
Basically, the idea is you have MAP/FILTER/REDUCE return functions that take a continuation
0:07:29
fwoaroof[m]
And you have another function that takes such functions and injects a function that builds up a result
0:08:29
sveit
fwoaroof[m]: i see. is SBCL magical enough that this performs comparably to series/loop?
0:09:13
fwoaroof[m]
In most cases, though, I expect it to be significantly faster than map/remove-if-not/etc., once your collections get significantly large
0:10:26
fwoaroof[m]
I think, in most cases, the performance difference with series/loop either doesn't matter because the collections are small, or doesn't matter because your code is more modular
0:13:04
sveit
yeah, the point of comparison is really series/loop, since the former works very hard to not build up intermediate collections, and in the latter you ensure this manually. i wonder more for the case of something like a nested loops over floats where you skip certain elements based on a predicate, otherwise call some function with side-effects on the float. the series case is as fast as a handwritten loop.
0:13:53
fwoaroof[m]
I suspect compiler macros for ALEXANDRIA:COMPOSE and for these functions can solve most of the performance issues
0:14:00
sveit
with enough inlining i would believe sbcl makes your continuation approach comparable, but i would have to check
0:14:56
fwoaroof[m]
I just think that the benefit of being able to use MAP/FILTER/REDUCE without intermediate collections and without compiler magic usually outweighs the performance difference
0:15:22
fwoaroof[m]
But, I'm generally on the expressiveness side of the performance vs. expressiveness debate :)
0:16:13
fwoaroof[m]
Which is dominated by the overhead of calling a closure in your implementation of choice
0:16:43
sveit
i usually fall on the performance side, but everyone i know that does software in a serious way is the opposite of me and like you, so i am slowly learning :)
0:17:39
fwoaroof[m]
I think from a cost standpoint, it's usually less expensive for a company to buy extra hardware rather than making their programmers less efficient
0:19:03
sveit
fwoaroof[m]: but despite it being a micro-optimization, i really do think in tight (numerical) loops it's worth getting rid of that closure. i basically think of series in this "transducer" way, but with lots of optimizations to remove function calls and fuse loops. and a couple of bugs :)
0:21:11
sveit
the other neat thing is if you are processing several series in parallel or use them more than once, it will tend to figure out how to loop over the series just once. for example, reasonable code to compute the mean and length of a series, which look like separate loops over a series, are compiled to a single loop.
0:22:21
sveit
i think it might be tricky to do this outside of the series approach, but maybe it's not even worth it to fuse the loops like this. apparently some hardware and compilers will de-fuse loops in fact :)
0:22:59
fwoaroof[m]
I use transducers in Clojure all the time for work, and I think they're one of the best parts of the language.
0:23:28
fwoaroof[m]
I should look into how series is implemented, though: it feels like a bad sort of magic, which has always put me off using it
0:31:19
sveit
fwoaroof[m]: the code is not too pleasant imo, but if you start looking at it/using it feel free to ping me again, like i said i have at least one trivial bugfix and can tell you what to avoid to keep series happy
5:49:36
edgar-rft
I'm afraid this will remain one of the unsolved mysteries nobody wants to know :-)
6:13:44
McParen
hello, is there a usual way to add additional documentation to an inherited slot in a subclass?
6:16:37
McParen
At the moment, I add all the inherited slots and the new docstring, but that leads to quite a mess, because it is hard to see what slots are new and which are inherited.
7:04:08
phoe
it's more like "be gentle" and "be wary" combined, given the repute that Hacker News comments section have
7:47:23
beach
McParen: I don't know the answer to your question, but it is a bit strange to want to document a slot.
7:48:12
beach
McParen: Slots are implementation details, so the only person interested in the role of a slot would be the person reading the code, and then a comment is the appropriate way to describe what the slot is for.
7:56:34
beach
Just having a lambda list that you determined yourself, as opposed to OBJECT is worth it.
7:57:16
beach
Well, you may want to use that one anyway, since the documentation is not meant for the same category of people who read the code.
7:57:31
flip214
beach: ah, thanks. that reminds me - I've got a patch in the pipeline so that in sbcl the accessors use the class name instead of INSTANCE.
7:58:24
McParen
beach: What would be the appropriate place to document functionality for the users of a library?
7:59:09
beach
McParen: Users/clients should not know about slots. For such a person, a class should be defined by its initargs and its accessors.
8:00:28
beach
Quickdocs is an aberration. Documentation can not be generated from documentation strings.
8:01:25
flip214
beach: I guess we need something like doxygen, to parse documentation from comments.
8:01:31
fe[nl]ix
beach: I'd be extremely grateful if you could point me to an actual documentation system
8:01:46
beach
It is not added value if a user starts using internal features that happened to be automatically documented, but that may disappear in the future.
8:02:24
beach
flip214: Like I said, comments are meant for the maintainer and documentation strings for the user/client.
8:04:00
phoe
anything that is not based on docstrings or comments is the problem that fe[nl]ix and beach are discussing at the moment.
8:04:27
fe[nl]ix
my current effort: https://sionescu.github.io/bordeaux-threads/threads/make-thread/
8:05:51
beach
Yeah, me neither. When I emulated the Common Lisp HyperSpec look for the MOP, I got a lot of crap for it.
8:07:58
fe[nl]ix
in a way it's funny that Texinfo can do all that, but the output is atrociously bad
8:09:27
Duuqnd
I think Document Examiner had a printing function though so you could probably print it with a virtual printer and get a PDF
8:09:36
beach
As I have often said, any markup language is bound to fail to get consensus, simply because there are so many of them that each one is supported by only a small minority of developers.
8:10:27
beach
That is why I want to see a documentation system based on CLOS protocols that determine what operations are possible, something that all markup systems seem to fail to provide.
8:11:42
fe[nl]ix
if you build a system that gives users the ability to organize in chapters, with cross-refs, indexes, etc...
8:12:27
jdz
beach: I've been intending to look at https://shirakumo.github.io/cl-markless/ one of these days, it seems to be at least halfway in the direction you describe.
8:13:06
phoe
http://www.bitsavers.org/pdf/symbolics/software/genera_8/User_s_Guide_to_Symbolics_Concordia_Book_Design.pdf
8:13:29
flip214
phoe: not the number of bytes is important, but to keep the changes minimal so that it's easier to see the real changes. Like whitespace cleanups should be a separate patch.
8:16:51
beach
Oh, wow, "Markless", yet another markup language. I wonder how many are created per time unit?
8:17:46
beach
I bet the selling point is that you can then generate output in the form of markup for pretty much all previously existing markup languages.