freenode/#sicl - IRC Chatlog
Search
17:28:35
beach
I think of cl-xyz as the name used for a library that provides Common Lisp bindings for a library named xyz written in a language other than Common Lisp.
17:29:56
beach
Just as I think of trivial-xyz as a library for unifying implementation-specific modules that are nevertheless widely used.
17:33:16
beach
Anyway, I need to go. It is my night to cook for my (admittedly small) family. I'll be back tomorrow as usual.
20:44:47
no-defun-allowed
I agree with ebrasca, cl-decentralise2 isn't a library for binding to a foreign library. But I don't like the name.
20:53:12
no-defun-allowed
Not really, I'm not sure how beach makes up names, except that they end up with "cl" in the name, possibly by changing a sound like "cl" to "cl".
21:50:29
no-defun-allowed
Silly question, I read that Cleavir will prove dynamic-extent declarations before stack allocating. Would it be possible to have a (non-portable) declaration that runs escape analysis on any binding? Then, say, I could ensure that a user of a mutex box isn't doing something stupid; for example, (let (x) (with-unlocked-box (x* box) (setf x x*))) may or may not be a problem.
21:55:29
no-defun-allowed
The declaration would have to accept different policies for what's okay with escaped values, say, I might have a list which I don't destructively modify, so that could escape, provided it's never destructively modified. But this analysis wouldn't be particuarly useful without verifying that the value won't escape through calling another function.
22:49:25
Bike
SICL will prove dynamic-extent declarations before stack allocating them. Cleavir does not include the part of the compiler that makes a policy decision like that.
22:49:55
Bike
Am I understanding correctly that the declaration you want is just dynamic-extent, but you want to be sure you get a warning if it's incorrect, and don't much care about the allocation?
22:51:29
no-defun-allowed
I think so, but in some cases, it might be okay to have a value escape, provided it isn't destructively modified.
22:56:06
no-defun-allowed
Not a lot. But the escape analysis is to make sure we don't use the value of a box, when the box isn't locked, and there are a couple of places where it might still be okay to pull a value out without copying it.
23:05:48
no-defun-allowed
Hm, that could get weird if you try to do something like an atomic POP on a list stored in a box. You don't share any values with the value of the box after releasing it, but the first value could be seen to have escaped.