libera/commonlisp - IRC Chatlog

8:03:37 beach I just discovered a bunch of Lisp-related videos on YouTube by Gavin Freeborn. Does Gavin hang out here?

8:50:44 waleee he drove by #nyxt about a year ago I think

8:51:19 waleee at that time at least he used his github-handle (gavinok)

8:53:22 beach I see. Thanks.

12:52:48 mfiano jmercouris: You can check out Monaspace for the "shiny-new font tech". I don't usually go running towards the light though...it gets pretty blinding

13:04:55 mfiano jmercouris: That said, it doesn't look too bad and has a nice idea/gimmick, though my current recommendation for readable code is Iosevka, one of the Slab variants, specifically.

13:07:34 supercode In https://www.lispworks.com/documentation/HyperSpec/Body/f_nconc.htm what does (nconc nil . lists) == (nconc . lists) mean?

13:07:41 supercode I mean what does dot (.) mean there?

13:08:56 mfiano it is reader syntax to separate the cdr of a cons.

13:09:11 mfiano (1 . 2) = (cons 1 2)

13:10:15 supercode I guess what I am unable to understand is what does (nconc . lists) mean on the right hand side.

13:10:22 supercode (cons nconc lists)?

13:11:12 supercode I am trying to understand the behavior of (let ((a nil) (b (list 10 20 30))) (format t "~a~%" (nconc a b)) (format t "~a~%" a))

13:11:54 supercode this prints (10 20 30) and NIL. which recursion rules there explains both outputs. that's what I am having trouble with.

13:13:35 supercode If this invokes this rule: (nconc list-1 list-2) == (progn (rplacd (last list-1) list-2) list-1) then should I not get an error when it tries (rplacd (last nil)) ?

13:13:53 mfiano any of the remaining rules

13:14:33 mfiano the . is basically &rest, and both syntaxes can be used in destructuring-bind's destructuring-lambda-list's to test.

13:15:00 mfiano s/remaining/subsequent/

13:15:02 supercode ok, let me share what I understand and please point to me where I am going wrong

13:15:15 bike it applies the second rule, (nconc nil . lists) = (nconc . lists). so (nconc nil (list 10 20 30)) = (nconc (list 10 20 30)).

13:15:38 supercode (let ((a nil) (b (list 10 20 30))) (nconc a b)). will this perform (nconc nil b) == (progn (rplacd (last nil) b) nil)

13:15:39 supercode ?

13:15:56 bike it will not rplacd.

13:17:17 supercode bike: just saw your message. I think that is explaining the behavior. let me take a few more minutes to wrap my head around it.

13:18:32 supercode bike: yes, that is it. so it does (nconc (list 10 20 30)) and returns (list 10 20 30) according to 3rd rule. And a remains unchanged as nil

13:18:43 bike yep.

13:18:50 supercode wow! so much going on here.

13:19:01 supercode I was expecting (let ((a nil) (b (list 10 20 30))) (nconc a b)) to set a to (10 20 30).

13:19:20 mfiano Also note that nconc is pretty special, and may be the only function that guarantees destructive modifications. Usually it is up to the implementation to decide.

13:19:32 supercode because (let ((a (list 1 2 3)) (b (list 10 20 30))) (nconc a b)) sets a to (1 2 3 10 20 30).

13:19:39 mfiano the only n* function, rather.

13:19:56 supercode does it not bother anyone that nconc does not set a to (10 20 30) in the former case when a is nil?

13:20:45 supercode would it have been trouble to implement nconc in such a way that (let ((a nil) (b (list 10 20 30))) (nconc a b)) would set a to (10 20 30)? why or why not?

13:21:35 supercode I guess one problem is that the CDR of nil is also nil, so there is no place to set the 2nd list to.

13:22:04 bike it would be impossible to do that

13:22:17 bike nconc is a function. it doesn't know anything about variable bindings. it just gets the lists as inputs.

13:22:22 supercode yes

13:22:26 supercode getting the hang of it

13:22:29 bike consider (nconc nil (list a b c))

13:22:34 bike nil is a constant. it cannot be modified.

13:22:57 supercode so 'a' really needs to be a cons cell if I want to make 'a' grow with nconc calls.

13:24:19 bike you can just do (setf a (nconc a ...))

13:28:02 mfiano I would be curious to know if there is any code out there using ,. that is 'acceptable code'.

13:34:09 mfiano ie; when is it useful to do such a thing at read time? it has only bitten me, by using comma in backquoted expressions that were variables beginning with a #\. in their name/

13:48:11 bike it's never acceptable, because anyone looking at it will go "wait, what the heck is this syntax" and be lost

13:52:39 mfiano Thanks for the confirmation.

14:12:41 dnhester26 I'm declaring a variable in a let and getting a defined but never used warning from the compiler, however, **I am** declaring it ignorable beforehand, so why am I getting the warning? am I doing the declaration in the wrong place? Here's the code https://plaster.tymoon.eu/view/4082#4082

14:13:12 dnhester26 the clhs doesn't have any examples... https://www.lispworks.com/documentation/HyperSpec/Body/d_ignore.htm

14:13:36 dnhester26 can anyone please add examples and/or explanations?? https://lisp-docs.github.io/cl-language-reference/chap-3/d-i-dictionary/ignore_ignorable_declaration

14:15:18 beach dnhester26: Is it json-params-name you are referring to?

14:15:42 dnhester26 beach: yeah

14:15:55 dnhester26 it get's set in the let with-json-params

14:16:09 beach No, it doesn't get set. It gets bound.

14:16:14 dnhester26 maybe I should've declared it inside the let??

14:16:15 beach So that's a different variable.

14:16:18 dnhester26 sorry bound

14:16:42 beach But that's probably what makes the difference.

14:17:27 dnhester26 hm I did not understand.

14:18:46 dnhester26 in the macro: defjson-route-with-preflight-params I am definitely using json-params-name

14:19:16 beach Where?

14:19:21 dnhester26 only in the with-json-params macro it's possibly not being used, but it's declared ignorable beforehand. Or should I declare it ignorable in that with-json-params macro??

14:19:35 dnhester26 (with-json-params (,json-params-name ,@route-params)

14:19:45 dnhester26 I am passing it down to wihth-json-params

14:19:57 dnhester26 *with-json-params

14:20:07 beach That expands to (let* ((,json-params-name...

14:20:25 beach So that's a different variable, because it is bound, not set.

14:21:20 beach If you have (let ((x 234)) (let ((x 345)) ...)) then the second X is not a use of the first one.

14:21:21 dnhester26 ah ok, that's what am not understanding between bound and set. Bound I thought was about slots in CLOS, set I thought was about any variable. How does that affect what am doing? Should I declare it ignorable in a different way or place in the code?

14:21:45 beach LET creates a new variable, it does not set an existing variable.

14:21:54 beach That's what it means to bind it.

14:22:31 dnhester26 thanks for explaining the difference between bind and set

14:22:42 beach I would think you need the IGORABLE declaration at the top-level body in your macro.

14:22:53 beach ... before `(defpost...

14:23:03 dnhester26 So in the let I am declaring a variable that is never used and that's why I get warning, but I declared it ignorable in the macro

14:23:26 dnhester26 why does the order make a difference?

14:26:01 beach You are basically declaring as IGNORABLE a variable that is not in scope in the resulting expansion.

14:27:24 beach Your macro defjson-... expands to (defpost... (declare (ignorable <some-name>)) But that variable no longer exists.

14:29:20 dnhester26 so the ignorable should be inside the let?

14:29:45 beach It should be outside the `(...

14:30:32 beach Consider this simplified macro: (defmacro bla (x) `(let ((y 234)) (declare (ignorable x)) y))

14:30:34 dnhester26 I tried but still gave me a warning

14:30:44 dnhester26 macroexpand for some reason is not expanding every macro

14:31:04 dnhester26 ah so it inside the let then

14:31:26 beach Consider this simplified macro: (defmacro bla (x) `(let ((y 234)) (declare (ignorable x)) y))

14:31:57 beach ,((defmacro bla (x) `(let ((y 234)) (declare (ignorable x)) y))) ,(macroexpand-1 '(bla 222))

14:32:03 dnhester26 in this simplified macro you are making the declaration inside the let, that's the point? because that's the context where the variable is defined?

14:32:17 beach ,(defmacro bla (x) `(let ((y 234)) (declare (ignorable x)) y)) ,(macroexpand-1 '(bla 222))

14:32:40 beach This is basically what you are doing.

14:32:55 beach Even if I do:

14:33:31 beach Sorry, give me some time.

14:34:05 beach ,(defmacro bla (x) (declare (ignorable x)) `(let ((y 234)) y)) ,(macroexpand-1 '(bla 222))

14:35:38 beach If I were to try to use the expansion of the first macro: ,(LET ((Y 234)) (DECLARE

14:35:38 beach (IGNORABLE X)) Y)

14:35:49 beach Sorry.

14:35:49 beach

14:35:58 beach If I were to try to use the expansion of the first macro: ,(LET ((Y 234)) (DECLARE (IGNORABLE X)) Y)

14:36:15 beach This is basically what you do.

14:38:59 beach You can safely do (defmacro defjson... (...) (declare (ignore json-params-name)) `(defpost-rout...

14:39:41 beach Er, no wait, that might not be right.

14:39:48 dnhester26 ah outside the backquote, I was doing backquote and comma, but the point is to do it outside?

14:40:37 beach My second example puts it there.

14:41:31 beach I am a bit tired, so my explanation might be off.

14:43:12 dnhester26 i am not really understanding. Is this basically what I'm doing (copy paste from your comment)? ,(LET ((Y 234)) (DECLARE (IGNORABLE X)) Y)

14:44:03 beach The expansion of your macro defjson-... will be:

14:44:29 beach (defpost-route... (declare (ignorable <some-name)) ...)

14:44:57 beach But <some-name is not in scope, so you are declaring a variable ignorable that is not in scope.

14:45:37 bike if this is the code in paste 4082, it looks like the ignorable doesn't even make it into the expansion

14:46:53 beach bike: What do you mean?

14:46:57 beach It is right there.

14:47:38 bike defjson-route-with-preflight-params, right? the code is (defmacro ... (declare (ignorable ,json-params-name)) `(defpost-route-with-preflight ...))

14:47:39 beach But in the expansion, there will be an IGNORABLE declaration of a variable that does not exist.

14:47:47 bike this doesn't even seem valid, it's got a comma out of a backquote

14:48:17 beach No, the code is not that.

14:48:19 bike dnhester26, have you edited this or something?

14:48:26 beach Oh!

14:48:33 dnhester26 i edited it

14:48:40 beach Oh, wow.

14:48:42 dnhester26 i should've just copy paste from my editor

14:48:51 dnhester26 one sec, I'll make a new one with copy paste

14:48:55 dnhester26 sorry for the confusion

14:48:59 beach dnhester26: I never told you to put a comma in there.

14:51:47 dnhester26 https://plaster.tymoon.eu/view/4083#4083

14:52:12 beach I should let bike do this.

14:52:22 dnhester26 beach: sorry that was a typo later that I fixed in the editor and instead of just copy paste i tried editing the pastebin with the same changes, my bad

14:52:39 bike sorry to add to the confusion here

14:52:39 dnhester26 bike: can you please take a look at the new one? https://plaster.tymoon.eu/view/4083#4083

14:53:23 bike this is wrong in kind of the opposite way from what beach was talking about, i think

14:53:38 bike if you want to declare a variable ignorable, you put the declaration where the variable is bound

14:54:18 bike here, you're declaring the _macro parameter_ json-params-name ignorable. this parameter is a symbol, a variable _name_. and it's pointless, since you always use it, on line 17

14:54:35 bike what you actually want to declare ignorable is the variable bound by with-json-params, right? or do i have that wrong?

14:54:36 dnhester26 in this new pastebin, I think the correct place is really line 15, not 13 as it is now, because that marcro is a progn with two lambda definitions and only the second one which is the body uses json-params-name

14:54:57 bike line 15 would be wrong, since that's not where the variable is bound

14:55:17 dnhester26 yeah, meaning some variable my-var that I am passing in

14:55:41 bike if you want to declare my-var ignorable you need to do that where my-var is bound

14:55:52 dnhester26 I get the compiler warning when calling defjson-route-with-preflight-params with some my-var saying it's unused

14:56:19 dnhester26 bike: so that should be line 3? but I was also getting the warning there

14:56:21 bike and that'll be on line 18, in with-json-params. (with-json-params (,json-params-name ,@route-params) (declare (ignorable ,json-params-name)) ,@body)

14:57:04 bike now say you have (json-route-with-preflight-params whatever myvar ...). The expansion will have (with-json-params (myvar ...) (declare (ignorable myvar)) ...)

14:57:28 bike the with-json-params form then expands into (let* ((myvar ...) ...) (declare (ignorable myvar)) ...)

14:57:31 bike which is just what youw ant.

14:58:08 dnhester26 bike: what's the difference between line 18 and 3? or for that case between lines 7 and 8?

14:58:21 dnhester26 bike: ah so it had to be inside the let?

14:58:36 bike the declaration needs to go where the variable is bound

14:58:40 beach It has to be where the variable is bound.

14:58:41 bike which in this case is the let* form

14:59:24 bike line 3 would be inappropriate, because then you are, again, declaring the MACRO PARAMETER json-params ignorable

14:59:47 dnhester26 bike: finally, just did it between 7 and 8 and got rid of the warning. So the whole problem was that it had to be **inside** the let scope. correct? that's what I was trying to understand

15:00:09 bike Yes, you put the declaration in the form that binds the variable.

15:00:28 bike (let ((foo ...)) (declare (ignorable foo)) ...), that's the syntax.

15:00:45 dnhester26 got it, ok, I think this is prime material for the technical reference, at least examples, or maybe I'm just a bit tired today

15:01:10 beach dnhester26: Again, in (LET ((X 234))... the variable X is not a reference, so declaring x ignorable outside the LET does not refer to that X.

15:01:19 dnhester26 beach: bike: thank you both! :D

15:01:24 dnhester26 yeah got it

15:01:28 beach Great!

15:02:17 dnhester26 the declaration is always after it's bound? or as long as it is in the same context it's OK? meaning could I do ,(let (declare (ignorable x))((x 24)))?

15:03:02 dnhester26 ok, so it looks like it has to be after the variables are bound from that error

15:03:25 dnhester26 so always in this order ,(let ((x 24)) (declare (ignorable x)))

15:03:41 bike ::clhs let

15:03:42 Colleen Clhs: special operator let, let* https://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm

15:03:49 bike let ({var | (var [init-form])}*) declaration* form* => result*

15:04:32 dnhester26 bike: ah wow, I never noticed that "declaration" in the syntax

15:04:35 dnhester26 that's great

15:05:01 dnhester26 thank you so much! I feel like my eyes have been opened a bit to notice the syntax better and understand this ignorable business

15:09:26 bike glad to help

15:23:09 dnhester26 :D

15:41:51 dnhester26 can anyone please proofread the examples for the ignore declaration I just added? https://lisp-docs.github.io/cl-language-reference/chap-3/d-i-dictionary/ignore_ignorable_declaration#expanded-reference-ignore-ignorable

15:42:11 dnhester26 are there any other examples that may be useful to know? or any other explanation that is good to write?

15:47:12 beach dnhester26: I would not use the term "statement".

15:47:18 beach Especially not for declarations.

15:47:48 beach dnhester26: The only mention of "statement" in the standard is in the equivalent of TAGBODY.

15:48:07 dnhester26 beach: what should I replace it with? the declaration and remove `declare`? saying the `declare` declaration sounds bad...

15:48:18 dnhester26 beach: thanks for the proofreading btw

15:48:25 beach Yes, "declaration" is good.

15:48:39 beach Also, you don't ignore the binding. You ignore the variable.

15:49:37 beach "after the variables" -> "after the bindings"

15:50:32 beach Replace ") (" by ") (" in (defun foo ...

15:52:58 dnhester26 beach: was that an extra white space in the defun?

15:53:04 beach Yes.

15:54:25 dnhester26 got it, thanks

15:54:39 Alfr dnhester26, nitpicking: (defvar *x* 42) (locally (declare (ignore *x*)) (1+ *x*))

15:55:14 beach What, what?

15:55:50 beach Alfr: What do you mean?

15:56:16 Alfr dnhester26, not sure if above still complies with "declaration must be within the scope where the binding happens".

15:56:40 Alfr beach, I'd expect a warning for using *x* withing that locally.

15:57:30 dnhester26 ,(defvar *x* 42) (locally (declare (ignore *x*)) (1+ *x*))

15:59:05 aeth dnhester26: you have to , each expression that's top level

15:59:10 aeth for the bot

15:59:20 dnhester26 Alfr: you mean that since the defvar is outside of the locally form?

15:59:27 dnhester26 aeth: thanks

15:59:29 aeth ,(defparameter *one*) ,(1+ *one*)

15:59:35 aeth ,(defparameter *one* 1) ,(1+ *one*)

15:59:37 aeth my bad

15:59:51 aeth coding live without an IDE, so tough

16:00:43 dnhester26 ,(defvar *x* 42) ,(locally (declare (ignore *x*)) (1+ *x*))

16:01:12 dnhester26 ,(defvar *x* 42) ,(locally (declare (ignore *x*)) (1+ *x*)) ,(princ *x*)

16:02:05 beach The compiler is not obliged to signal warnings for any of these cases.

16:02:13 dnhester26 Alfr: thanks for the proofreading. Did you mean that since the defvar is outside of the locally form?

16:02:54 aeth are you trying to incf it instead of 1+ it or...?

16:03:14 dnhester26 beach: maybe Alfr means that the way I wrote it implies there should be a warning, and the language has to be changed.

16:03:21 dnhester26 this is the sentence I wrote: "A key point to declaring variable bindings to be ignored is that the declaration must be *within* the scope where the binding happens."

16:03:41 dnhester26 So here the declaration is not within the scope

16:03:57 dnhester26 aeth: I was just trying to execute the example Alfr wrote ;)

16:04:42 beach It is within the scope, but it is not a bound declaration, and it's iffy anyway to have special variable declared IGNORE.

16:05:03 dnhester26 beach: Oh, and I think I now understood what you said: since there is no warning anyway, there is no need for the declaration either

16:05:41 dnhester26 beach: in conclusion: should I leave the text as it?

16:05:59 Alfr dnhester26, in a sense it is, should be in the global environment. But, yeah, textually it isn't,

16:06:09 beach *sigh*

16:06:19 beach Declarations can be "bound" or "free".

16:06:54 beach In a LOCALLY, declarations are "free", but they are still in scope if the are in scope outside the LOCALLY.

16:07:44 beach So in (locally (declare ignore *x*) ...) the declaration is free, but since the variable is bound in the global environment, the declaration is in scope.

16:08:42 beach It also does not make much sense to me to have free IGNORE or IGNORABLE declarations.

16:08:54 beach At least I can't think of a use case for such a thing.

16:09:45 aeth ,(declaim (ignore *x*)) ,(defvar *x* 42)

16:10:07 aeth ,(declaim (ignore *x*)) ,(defvar *x* 42) ,*x*

16:10:17 aeth ,(declaim (ignore *x*)) ,(defvar *x* 42) ,(progn *x*)

16:14:05 beach I mean, if you have (let ((x 234) (y 234)) (locally (declare (ignore x)) y)), then X is still unused in the (locally ...) form. And in fact, SBCL gives a style warning for a free IGNORE declaration.

16:14:41 beach And, again, SBCL gives a style warning that X is not used.

16:15:12 beach So I maintain that it doesn't make much sense to have free IGNORE or IGNORABLE declarations.

16:18:12 Alfr beach, that's when you want to check that you used everything you introduced. But does make sense when you want a warning for using *x* with that scope.

16:18:30 Alfr within*

16:19:07 Alfr ... and before you ask, no idea if it's actually used that way.

16:19:11 beach SBCL gives a style warning for IGNORE declarations of special variables.

16:20:08 Alfr ... guess that's a no.

16:21:27 beach Well, here is how I see it. Special variables have dynamic scope, but declarations have lexical scope. So if you do (let ((*x* 234)) (declare (ignore *x*)) (foo)), then you won't know whether FOO uses *x*.

16:22:01 beach So then what does it mean to not use *x* within its scope?

16:22:40 beach Should you be given a warning of FOO is inlined, but not if it is not?

16:23:01 beach *a warning if FOO...

16:25:16 beach So I think SBCL is doing the right thing here. Signal a style warning for free IGNORE and IGNORABLE declarations, and for IGNORE and IGNORABLE declarations of special variables.

16:26:11 Alfr beach, fine ... in (let ((foo 21)) (list (locally (declare (ignore foo)) foo) (* 2 foo))) I want a warning for the foo producing the first list element.

16:26:59 Alfr ... and I see that sbcl complains that the ignore is about a variable from "outer scope". xD

16:27:04 beach I see your point.

16:27:17 Alfr ... so doesn't work as envisioned.

16:27:22 beach Yes, SBCL could have used the proper term "a free declaration".

16:28:39 Alfr beach, and I don't know an answer to whether macros expanding to such should or should not trigger such a warning.

16:29:11 beach Yes, good question.

17:52:20 gaze_____ ** NICK gaze__