freenode/#lisp - IRC Chatlog
Search
12:50:16
phoe
I'd translate one of the solutions from https://rosettacode.org/wiki/Stable_marriage_problem since the problem is well-documented there.
12:53:32
phoe
No, I just guess nobody ended up doing it for any reason. Things in the programming world appear only if someone writes them.
12:53:47
phoe
The algorithm seems to be four functions in total. Translating it from any other language would be pretty simple.
12:55:23
phoe
You have both a very good explanation of the problem and the algorithms AND solutions in multiple other languages. Translating this to CL is nothing that I'd call complicated.
12:56:35
nirved
looks too simple to bother, almost same number of lines as the pseudo-code here https://en.wikipedia.org/wiki/Stable_marriage_problem#Algorithm
12:57:02
phoe
wxie: first you translate it from another programming language, and then fix up the code so it's a bit more idiomatic CL.
12:58:02
phoe
I've seen CL being used to write object-oriented code, functional code, imperative code, linear code, declarative code, asynchronous code and a few of other lesser known paradigms. Hard to say that any of these were "unlispy".
12:59:11
phoe
The part of what I'd call "lispiness" is that a person X comes up and say "hey, I just invented this new programming paradigm!" and Common Lisp is all like "come at me bro"
13:00:55
wxie
for example, I come up with (push (cons (car pair) (cadr pair)) where pair is ((w1 . m1) (w2 . m2)). I am thinking if there is other ways to do it.
13:02:11
phoe
so basically, you have a two-element list, and you want to make a cons from that list, and push that cons to some kind of place called pairs.
13:05:00
_death
(defun repair (list) (cons (first list) (second list))) (push (repair couple) pairs)
13:07:36
phoe
wxie: maybe a better question: what is your definition of "lispiness" that you speak of?
13:08:52
_death
wxie: but here's an old snippet https://gist.github.com/death/d88bc1331902da52b7c2d08c4ec093d6
13:08:53
phoe
that's an option, yes - especially if your inner loop will or may evolve into something bigger.
13:10:40
wxie
phoe: I am not so sure about my idea of lispness because I have limited experience anyway.
13:12:21
phoe
And I'm just wondering whether and how much this idea matches actual CL and how it's used.
13:13:38
wxie
Right, for me lispiness means using list as much as possible, using setf or the like as little as possible.
13:13:49
phoe
And it's going to be interesting regarding the "how it's used" part because _death just showed some code that I wouldn't have written because I have a completely different coding style and, for example, I wouldn't have used fset.
13:14:11
phoe
That sounds pretty Scheme-like. They have a focus on functional programming and preference for immutability.
13:14:46
phoe
Common Lisp tends to not favorize functional programming, and it embraces mutability as a standard and expected feature for the language and its users.
13:33:37
wxie
phoe: Yes, it prints. I need spend sometime on it. Just want to know how do you know that you need fset?
13:34:01
phoe
wxie: the package definition on top of this file shadowing-imports-from the FSET package.
13:35:15
wxie
I know. But when you have the problem, you need think over it, and then you know need some packages that are already there.
13:35:59
phoe
Yep. I bet that this problem can be solved without FSET, but the solution is much clearer when using FSET.
18:52:21
aeth
My quick review of what I read of Common Lisp Recipes: The author seems to go with the community consensus on everything where the consensus exists except preferring his own cl-fad over uiop for path/file-related things, but you can't really fault someone for prefering their own library.
18:53:03
aeth
The weakest part is probably if you're trying to make something graphical, but that's probably the weakest part of the CL ecosystem anyway, and that could definitely be enough material for its own book(s)... ideally after such libraries are more mature.
20:00:04
mfiano
There is also at least 1 thing that cl-fad does much better than UIOP, or at least until implementations such as SBCL update their ASDF
20:10:13
rpg
mfiano: That may be, but there are lots of things that CL-FAD does worse than current UIOP. In particular, the treatment of directories versus files in pathnames, in CL-FAD is very weak.
20:11:02
rpg
That's because Fare did a ton of hard work to figure out how much information he could squeeze out of the various implementations.
20:11:17
mfiano
I completely agree, but Fare fixed a major performance issue I reported a long time ago that has not propagated to all of the common implementations yet.
20:15:04
mfiano
Yup, I've been waiting a while for SBCL to update ASDF, which I hear is happening soon. With UIOP, listing files in a directory with thousands of files takes minutes, compared to near instantaneously with cl-fad.
20:37:07
osune
hoi, for StumpWM I want to write a 'one-shot' hook. stumpwm:add/remove hook both take a symbol. To realize the 'one-shot' ability I need to write a closure which will take a function, calls the function and calls stumpwm:remove-hook on its own symbol. I wrote following function for this: https://pastebin.com/QGaWVgxZ ; It does what i expect: returning a new symbol which binds the closure. But the stumpwm:remove-hook call doesn't work
20:42:27
osune
Bike: after triggering the hook, which executes the supplied function correctly, the stumpwm:remove-hook call doesn't seem to affect the supplied hook list (a list with function binding symbols). The hook list still contains the gensym binding the closure.
20:45:38
osune
stumpwm:remove-hook is a macro expanding to (setf hook (remove fn hook)) https://github.com/stumpwm/stumpwm/blob/aa8f9560461b5e0010db417a1224c911ba705563/primitives.lisp#L691 ;
20:47:29
osune
currently my guess is that it has to do with the (gensym) call; but I'm not sure and I don't know where I could find a discussion about the differences of interned and uninterned symbols
20:51:50
Bike
it's basic. (defvar *foo* 9) (defun test (x) (setf x 3)) (test *foo*), then *foo* is still 9.
20:54:06
osune
but that means I can not evaluate *foo*; which means I need a macro for that. Is this correct?
20:55:27
osune
thanks. just to be sure, is there anything which would achieve the same without using a macro here?