freenode/#lisp - IRC Chatlog
Search
7:21:18
White_Flame
What's the most idiomatic way to combine remove-if-not (filter) and mapcar (transform) in a single pass?
7:27:58
phf
edgar-rft: thank you for doing the legwork! i also reached out to author, but haven't heard anything back yet
7:31:08
aeth
White_Flame: if you don't like loop you can just write your own macro or higher order function on top of it
7:32:11
aeth
dialectic: I'd use iterate if it was just loop with parens and extensibility, but it's its own very different thing that I can't expect people to be able to read
7:32:39
White_Flame
and I'm sure loop hides faster imperativeness than I want to bother implementing myself
7:33:48
dialectic
Perhaps. That's a fair criticism. I didn't regret the one day it took to learn it, though. I never use loop anymore.
7:36:26
phf
White_Flame: at least on cmucl (loop when ... collect) expands into a tagbody with setq's and go's, so yeah, not something you might want to write yourself
7:36:50
aeth
one macro that would be fun is one that is essentially a miniature computer algebra macro
7:37:16
dim
loop/iterate, there's also the “for” macro but I can't seem to be finding the repo again easily
7:39:14
aeth
On the surface, SUM would look like LOOP's sum clause, but under the hood it would be using https://en.wikipedia.org/wiki/Summation#Identities because it would have more restrictions on what can be summed
7:46:47
dim
ahah, found it, the for looping macro is at https://shinmera.github.io/for/ and it looked interesting, it's on my “list” of things to try someday
7:48:25
aeth
you can't use FOR and ITERATE in the same package without prefixes because ITERATE has this weird thing with symbols and expects to be :USEd, unlike LOOP, which accepts any package. So for:for and iterate:for will collide
7:49:05
aeth
interestingly, according to that page, for is basically intended to be used with its package prefix... so as for:for
7:49:55
White_Flame
this is literally what keywords are for. why are the underused in places like this?
7:52:33
aeth
White_Flame: that's one of the places where my macro would differ from FOR/ITERATE/SERIES/etc. I like keyword-utilising LOOP because it makes the ALGOL-style keywords stand out as, well, Lisp keywords
7:52:56
aeth
White_Flame: But, yes, keywords aren't really used because it's intended to be extensible.
7:53:11
aeth
I guess you could keyword the built-ins and expect the extensions to be namespaced, but that could look weird
7:58:08
aeth
but that's only for the first part of a clause. If you're doing (:for x :from 1 :to 42) the rest of the clause should have keywords. Then you can implement that as a plist tail and have order not matter and internally use destructuring-bind with &key
8:03:44
aeth
inspecting it in SBCL, I get the subclasses: (#<sb-pcl::condition-class sb-di:debug-condition> #<sb-pcl::condition-class sb-sys:interactive-interrupt> #<sb-pcl::condition-class sb-ext:timeout> #<sb-pcl::condition-class common-lisp:storage-condition> #<sb-pcl::condition-class common-lisp:error>)
8:04:37
aeth
most of these are internal to SBCL, but that means that your implementation might add others on top of the two specified, and libraries might add others
8:14:23
aeth
It's interesting that CCL uses standard-classes and SBCL uses sb-pcl::condition-classes
12:33:23
drmeister
What's the poop with compiler macros and the slime interactive macro expansion. Is it not supposed to expand compiler macros - or is it an implementation dependent detail?
12:41:08
drmeister
Hmmm, do you know why? I kinda hoped I could expand compile-macros with it because I've got some gnarly code expansion going on. Reading the slime code I see it talks about compiler-macros but I don't see where it uses their expansions.
12:59:49
LdBeth
If you’re interested in how compiler macro expands, you get the sense that compiler macros work exactly as ordinary macros
13:21:04
pfdietz
My complaint with ITER is that it breaks Waters' COVER. The latter is cheating slightly, but usually isn't caught at it. ITER is an exception.
13:43:03
dtw
If there is a :test key argument for function (e.g. (position item sequence :test ...)) is there a guarantee for a specific order of arguments for the test function? The spec _could_ be interpreted that "item" is given first and "sequence's" element (or value of :key function) is second. It's not totally clear, though. http://www.lispworks.com/documentation/HyperSpec/Body/17_ba.htm
13:44:44
dtw
I'm using (position-if ...) so I get to build the test function myself. I'm just curious how you interpret the spec.
13:47:08
dtw
This whole question is not meaningful with EQL or such symmetrical test functions but with > or < it's important.
13:50:19
pfdietz
"(for a two argument test) to be in a state such that the two-place predicate which is the sequence function's test argument returns true when given a first argument that is the object being considered, and when given a second argument that is the result of calling the sequence function's key argument on an element of the sequence function's sequen
13:51:28
ggole
Seems as if both the glossary and the page agree that 'the object', eg, the value that is not an element, is the first argument.
13:53:23
pfdietz
And for the set functions (UNION, etc.) it's almost certainly bad form to depend on a particular order.
13:53:56
pfdietz
BTW, this makes me want some sort of categorical notion that links equality functions with hash functions.
13:55:04
dtw
pfdietz: Thanks. Indeed it reads there in the glossary. For code-reading human it's probably better to use *-if and *-if-not functions.
13:57:15
ggole
pfdietz: do you mean x = y implies hash x = hash y (the usual requirement)? Or did you mean some lower level thing to do with ensuring that holds?
14:00:21
Xach
hmm: (401 "Unauthorized" from #<GITHUB-REQUEST :GET to "https://api.github.com/repos/sionescu/fiveam/releases">)