freenode/#lisp - IRC Chatlog
Search
14:48:59
rumbler3196
anyone having issues with paredit mode lately? Its letting me delete closing parens which is frustrating
15:03:03
Xach
rumbler3196: I don't use anything. If a form becomes too long to use simple paren balancing in the REPL, i write it in a file (sometimes a temporary one) to manage it.
15:38:08
pjb
note that paredit disables itself when parentheses become unbalanced in a buffer, outside of its control. So: (write-line "1) then repl is not a lisp buffer!")
15:43:50
rumbler3196
paredit in the scratch buffer works fine. I issue m-x slime and then activate paredit and parens don't keep
15:46:36
rumbler3196
this is where I get mixed up sometimes. I installed slime from the package manager, then after I installed quicklisp I installed the quicklisp-slime-helper
16:25:44
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=97a2b8a1 will be valid until 16:30 UTC.
16:30:58
jasom
A stackless coroutine is a coroutine that cannot context-switch in a nested function.
16:32:30
samlamamma
Finally a proper reason to use Common Lisp. http://quickdocs.org/trivial-left-pad/api
16:32:57
jasom
Josh_2: so the "stackless" part is that the TCB for the coroutine need not include a separate stack.
16:37:00
Bike
wouldn't the issue be that you can only resume the yielded coroutine at certain points, that is while the condition is being handled? you can't actually return to the caller and do something you were already doing.
19:49:27
jcowan
Can sbcl statically type-check keyword actual arguments when the type of the corresponding lambda argument is known?
20:23:34
pfdietz
If you declaim the type of the function using FTYPE, it will flag the type incompatibility at the call.
22:58:56
jcowan
Another question. If a lambda list specifies both &optional and &key, is it necessary to fill all optional arguments in the call before any keywords are detected, or is the presence of a keyword enough to trigger keyword processing?
23:01:16
no-defun-allowed
You can test with read-from-string, which takes two optional arguments then keyword arguments.
23:06:11
clothespin
i'm not talking about the heavy handed stuff like immutable datastructures and atoms and such
23:06:53
aeth
jcowan: (let ((l1 (list 1 2 3 :c 42)) (l2 (list 1 :c 42))) (flet ((test-optional-with-key (list) (destructuring-bind (foo &optional bar baz &key a b c) list (values foo bar baz a b c)))) (format t "~{~S ~}~%~{~S ~}~%" (multiple-value-list (test-optional-with-key l1)) (multiple-value-list (test-optional-with-key l2)))))
23:07:04
aeth
SBCL even gives a style warning there, although it exists in a few older functions in the standard
23:08:09
aeth
For those who don't want to run it, the first line is "1 2 3 NIL NIL 42 " and the second is "1 :C 42 NIL NIL NIL ", so when the optionals aren't filled in the keyword is treated as an argument. And yes, this has caused a bug in my code before.
23:10:07
aeth
And without destructuring bind: (let ((l1 (list 1 2 3 :c 42)) (l2 (list 1 :c 42))) (flet ((test-optional-with-key (foo &optional bar baz &key a b c) (values foo bar baz a b c))) (format t "~{~S ~}~%~{~S ~}~%" (multiple-value-list (multiple-value-call #'test-optional-with-key (values-list l1))) (multiple-value-list (multiple-value-call #'test-optional-with-key (values-list l2))))))
23:31:35
aeth
SBCL does have the most helpful compiler, it warns you about stuff like a special variable without earmuffs. CCL can catch some bugs that SBCL doesn't because it interprets the standard differently, though
23:32:59
aeth
jcowan: The default value of optionals and keywords are nil unless you specify one like &optional foo (bar 42) ; in this case foo is nil and bar is 42 if nothing is passed in
23:33:28
aeth
jcowan: In CL, there is no #<unspecified> or whatever a Scheme might use for stuff like that. Pretty much anywhere where there is a default value, it's nil, unless you explicitly use (values) or use an API that does
23:34:48
jcowan
So in fact you must specify all optional arguments, none can remain optional, if keyword arguments are to be processed as such.
23:35:34
aeth
jcowan: It does make sense from the perspective of &optional, which is to get to the later, you have to go through the earlier parts, even if it just means a bunch of ugly nils that were already the defaults
23:35:47
Bike
it would probably be even more complicated to try to interpret it another way, given the other parts of how keyword arguments (you can use non-keyword symbols, and pass keyword arguments not specified in the lambda list, plus you don't statically know the lambda list anyway)
23:36:31
jcowan
I'm beginning to grasp why Racket and Kawa treat keywords as syntax rather than Lisp objects.
23:37:05
Bike
yeah i kind of like how lisp works well enough, but it does have some really confusing parts
23:37:09
aeth
jcowan: Right, because if you see :foo :bar :baz :quux you don't know if you have 0, 2, or 4 keyword arguments.
23:37:33
jcowan
I think the moral is not to mix keywords, optional arguments, and rest arguments: pick one.
23:38:33
aeth
jcowan: &allow-other-keys is imo pretty much mandatory in higher order functions (at least ones that take in lambdas that use keywords) in Common Lisp because you can't pin a library to a version in Quicklisp, so if an API adds another keyword input, your version is now an error at whatever point it's funcalled.
23:41:47
aeth
There's some advantage to simple lambda list syntax, e.g. you can destructuring bind a plist tail with (... &key ... &allow-other-keys) to parse it... That's convenience you don't get for alists.
23:42:53
jcowan
whereas even if keywords were not self-evaluating, (foo 'a 32 'b 45) is perfectly readable and no more verbose than :a :b