libera/#commonlisp - IRC Chatlog
Search
10:43:57
susam
gigo: Okay. I have been writing my personal tools in Common Lisp for the past few years but I am still learning something new from your questions.
10:45:42
susam
gigo: We had a PCL reading group sometime back where I used to take notes from the book and archive it for our group. I remember reading about with-standard-io-syntax but did not investigate it like you did, i.e., making test cases where not having it would lead to failure. I am planning to include these test cases given by phoe to our notes.
10:46:36
beach
kakuhen: Documentation for a slot is somewhat of an aberration, since slots are implementation details and do not merit any external client documentation, which is what documentation strings are for.
10:53:51
beach
tfb: I was answering the question of who reads and writes such documentation, not whether it belongs in the language or not.
10:56:34
tfb
beach: I think the statement that 'documentation strings are for external client documentation' is simply wrong: documentation strings are for whatever they are used for
11:02:30
edgar-rft
tfb: there's (documentation (x structure-class) (doc-type (eql 'type))) -> http://www.lispworks.com/documentation/HyperSpec/Body/f_docume.htm
12:11:26
Guest63
can we re-use their names for multiple classes (e.g. two classes can have the same accessor name)?
13:05:01
phoe
oh wait, https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ is still a better resource
13:09:23
coat
practical common lisp is freely available online so I will start with that one. will buy gentle intro to symbolic computation after I have worked thru practical common lisp
13:12:45
Guest63
coat: it's a bit easier to read IMO (but others like PCL, so this is just an opinion), PCL may be useful as a second book
13:14:02
Guest63
the author of ansi cl btw is the founder of ycombinator, and now a multi billionaire - never knew writing books was so lucrative!
13:17:14
Guest63
also a gentle introduction to symbolic computing is available for free online (i note you said "buy"):
13:18:22
Guest63
imo its a good read but too long winded. I find it good to read another book first to get some basics in your head - THEN read AGITC - THEN go back to your original book and everything will click better
13:19:09
Guest63
but as a first read, it might be too slow and detract readers (its gentle pace is really helpful in explaining concepts, but IMO you don't realise why those concepts are important and need explaining until you get a bit of experience and then start asking the questions yourself)
13:39:52
tyson2
I find the practical examples in PCL are more interesting to read, then I go back and check out the topics I don't understand (have been using scheme and elisp for a while)
13:57:32
jcowan
On internal DEFPARAMETER, you can get very strange-looking things to happen: considere (progn (let ((gong 42)) (defparameter gong 50) gong) gong), where gong apparently escapes from the let-binding.
14:10:30
edgar-rft
the more interesting thing is that when I evaluate (let ((gong 42)) (defparameter gong 50) gong) for the first time, when no special var gong exists, it returns 42, while from the second time on it returns 50
14:13:27
edgar-rft
but shouldn't gong be declared special already after (defparameter gong 50) in the first evaluation, I mean the return value, not in the let binding
14:14:00
phoe
edgar-rft: the proclamation happens after the compiler infers that GONG refers to a lexical variable
14:14:25
phoe
the second time this code is compiled, the compiler knows that GONG is globally special
14:14:45
phoe
the confusion happens because there are actually two variables in play here: a lexical one named GONG and a dynamic one named GONG
14:16:15
edgar-rft
but in (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong) the declaration also happens *after* the let binding and it returns 50 at the first try
14:19:39
edgar-rft
so (declare ...) is considered at an earlier time than (defparameter ...) in the compiler?
14:20:21
edgar-rft
phoe: I'm talking about (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong)
14:21:22
_death
edgar-rft: the defparameter form is not a top-level form, so the compiler may not recognize it
14:22:36
edgar-rft
but I have to read the spec to make sure I understand what I am talking about :-)
14:24:05
Guest63
"Constructs that use lexical scope effectively generate a new name for each established entity on each execution. Therefore dynamic shadowing cannot occur (though lexical shadowing may). This is of particular importance when dynamic extent is involved."
14:24:29
_death
there was discussion about top-level bindings yesterday.. recently I looked at the chinual (for a reddit comment) and also noticed there was a LET-GLOBALLY operator
14:25:27
_death
which may be similar to what people nowadays call LETF.. but maybe had some difference with regards to this specific case
14:32:42
scymtym
we worked a little bit on the process for creating WSCL (which beach mentioned above). in case anyone wants propose a clarification regarding non-toplevel DEF{VAR,PARAMETER}, a pull-request that fleshes out https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/DEFPARAMETER-NON-TOPLEVEL-SEMANTICS would be welcome
14:38:19
scymtym
_death: yes that's wrong. the file is meant as a starting point which illustrates the format. to be honest, i didn't follow the discussion closely since i'm focusing on the infrastructure. it's just that having such as discussion without writing down any insights seems like a waste
14:52:42
_death
scymtym: well, I'd expect the first form to return (3 1) .. don't see how it could return (2 2) since there's no lexical binding there
14:57:46
scymtym
i think i wanted to write (2 3) but i rushed it a lot to have an example ready. the point is, why not write down different possible behaviors and the respective pros and cons as well as the behavior of existing implementations
15:42:17
_death
I don't think I ever used non-toplevel defparameter/defvar.. are there any known uses in the wild
15:46:09
jackdaniel
_death: LETF (at least in mcclim codebase) is a "let for places" - that of course breaks for multi-processing code, but it is ~ (let ,remember-old-vals (unwind-protect (progn (setf ,@store-new-vals) ,@body) ,@restore-old-vals)
15:51:34
_death
jackdaniel: right.. unlike letf, it was unaware of places.. but it did set variables.. re-reading its description, I guess it had more to do with stack groups
15:53:13
jackdaniel
funny break scenario for climi::letf is trying to bind the unbound slot (something that could be worked around if really necessary)
15:58:57
_death
there are other funny facts with LML.. e.g., it had defvar but its defparameter-like was called defconst.. the case-like operator used to be called selectq (the q meant the keys were not evaluated) and there was an evaluating case called select (and also selector, which let the programmer specify the comparison function).. sometimes it looks like CL has simplified operators that were gnarly in LML
16:01:33
_death
well, an alias, but it existed for "maclisp compatibility", though it was different from maclisp's :)
16:19:38
Bike
i'd just write it yourself and if it turns out to be in a utility library all the better
16:41:49
jackdaniel
otoh doing it that way may invoke unnecessary protocols (because it always modifies the place) - the same problem would apply to reverse-orf I think
16:46:05
_death
a reverse-orf thing (there must be some proper word to describe the operation :) could also avoid evaluating parts of the place if the value is nil
16:49:00
_death
maybe less surprising if the order of evaluations is reversed, like in PUSH.. (stamp value place)
22:06:30
jmercouris
anyone know of any attempts to create a 'visual' programming interface for lisp?
22:07:08
jmercouris
of course it would be a new language, but borrowing as many concepts from lisp as possible
22:10:59
jmercouris
this looks really intense, I think I could tone it down and provide some of the same concepts more approachable for beginners