libera/commonlisp - IRC Chatlog
Search
7:23:05
hayley
I only actually have one copy, but I had both my own copy, and had borrowed the university copy for a short period of time.
7:24:17
hayley
Coming up on having borrowed the Garbage Collection Handbook without interruptions for a year. Richard Jones told me if I hold out for a few more months, I could get the new edition.
7:27:20
hayley
Well, I hope it's a year. I have the little slip of paper that fell out, with "PATTON, HAYLEY 19.07.21" written on it, but the online system says I borrowed it on the 14th. Granted, it took a week for the library to find the book.
8:32:58
beach
rendar: The garbage-collection handbook? Sure, if you are interested in automatic memory management. It has a description of all the major techniques and their characteristics. And there is no other book like it.
8:32:59
hayley
AMOP or the GC Handbook? I only bought the former, but the latter would be a good investment too.
8:33:44
beach
rendar: However, it is not very well written, though perhaps the new edition will be better. I suspect not, however.
8:33:51
hayley
Though, yes, as beach says, the latter is only useful if you want to work with garbage collection.
8:34:46
hayley
The description of the Lisp-2 compaction algorithm is going to be better in the new edition, at least.
8:37:06
hayley
Yeah, I often found I needed to look at the papers cited in order to understand what was going on. But having those references is also useful.
8:37:59
beach
hayley: Of course, now that I think about it... I often say that I think that in order for someone to be a good programmer, that someone needs to know about computer architecture and compiler techniques. Maybe I should add "memory management (automatic or manual)" to that list.
8:38:54
hayley
In particular, I can never remember the name "Java server performance: a case study of building efficient, scalable Jvms" which is relevant to my current work. The paper on Immix cites a website by IBM that does not exist anymore, but the GC Handbook cites that article instead.
8:40:04
beach
rendar: But it is a very important book. Alan Kay said it was one of the most important CS books ever written, or something to that effect.
8:41:46
hayley
On the other hand, he said it was hard to read if you weren't familiar with Lisp. Which I can understand, honestly, as I think Dylan would have been the only other language with generic functions, in 1997.
9:06:11
hayley
In a Hacker News comment, Alan Kay also gave the praise "I liked the MOP book because they carried the model more deeply into the actual definitions -- I very much liked their metaphor that you want to supply a "region of design and implementation space" rather than a single point."
9:28:28
pjb
beach: (let ((&allow-other-keys 10) (x 20)) (write &allow-other-keys x)) #| ERROR: Incorrect keyword arguments in (20) . |#
9:34:04
_death
pjb: this error has nothing to do with the &allow-other-keys.. (maybe you confused it with :allow-other-keys)
9:48:51
_death
also happily, beach's idea of renaming seems fine, because &rest etc. cannot be declared special by the user.. though I guess if there are some implementation-specific lambda-list-keywords it may be an issue (but sbcl has a package lock on sb-int:&more, so no issue there)
10:10:06
TMA
I cannot find whether it is specified for &rest etc. to be present or accessible in the COMMON-LISP package.
10:11:55
specbot
Symbols in the COMMON-LISP Package: http://www.lispworks.com/reference/HyperSpec/Body/01_i.htm
10:12:12
specbot
The COMMON-LISP Package: http://www.lispworks.com/reference/HyperSpec/Body/11_aba.htm
10:15:31
TMA
ah, I was a bit baffled by the glossary entry "lambda list keyword n. a symbol whose name begins with ampersand and that is specially recognized in a lambda list."
10:17:31
TMA
that has two readings, namely that (a) the &-beginning-symbol is specially recognized in a lambda list and (b) that the &-beginning-symbol's name is specially recognized in a lambda list.
10:19:22
TMA
the (b) reading would allow (lambda (&rest x) x) and (lambda (#:&rest x) x) be equivalent (in the same spirit as the loop keywords are specified by name only)
10:19:46
_death
it's a conjunction.. it has to (i) begin with an ampersand (ii) be specially recognized in the lambda list
10:25:12
TMA
lambda-list-keyword(x) === (let ((that ...)) (and (eql (elt (symbol-name x) 0) #\&) (specially-recognized-in-a-lambda-list-p that)))
10:26:16
_death
I can see how you could read it as "a symbol whose name (begins ... and that is specially recognized ...)" but only if you remove the context of lambda list parsing as described in the clhs
10:28:53
nij-
phoe I bought a phys copy of your book on condition system. It's great so far :D Thanks!
10:31:33
TMA
_death: well, I can argue against myself that the wording in 6.1.1.2 Loop Keywords is explicit enough that the intended meaning is not the .../(symbol-name x) substitution, because there is not enough of similarly explicit wording for lambda list keywords
10:32:50
nij-
1. I wonder why can't we use if/case forms to handle different conditions. Isn't that simpler?
10:32:54
nij-
2. I've heard many times that Lisp's condition system is better than other langs'. However, Python for example has a debugger too. In what way is the Lisp condition system better than Python's (or any other lang's)?
10:33:02
nij-
3. You mentioned that *-bind are macros but not functions (chapter 4) and therefore cannot be operated functionally. While macros are great for extending Lisp syntax, does this show that macros have their (serious?) limits too?
10:33:20
TMA
but the specification lawyer in me cringes, I have been trained to spot those minor ambiguities in standards; it turns out those are lagely intentional loopholes
10:33:49
_death
lambda-list-keywords is a constant variable that contains a list of all the lambda list keywords.. if the definition had been about names, it'd be hard to cons :)
10:36:41
TMA
"A list of all the lambda list keywords used in the implementation, including the additional ones used only by macro definition forms."
10:37:43
TMA
it still keeps a bit of wiggle room for symbols that are recognized by the implementation but not used in it
10:44:15
pjb
TMA: note: (defun specially-recognized-in-a-lambda-list-p (x) (member x lambda-list-keywords))
10:44:55
pjb
TMA: so really the &-beginning-symbol-p in the definition is only a constraint on what is in lambda-list-keywords.
10:45:32
pjb
TMA: so you're right that a #:&REST or a SI:&REST symbol could be in lambda-list-keywords, but we've never seen them. (implementation dependent).
10:45:56
pjb
Alsok it would be hard to use #:&REST since you'd have to find it in lambda-list-keywords for reference.
10:46:06
hayley
Not phoe but: #1 Conditions are "non-local" in that they interact with code that isn't nested in the forms, like IF and CASE do. 2. The debugger isn't that important in itself, but not unwinding and losing information is important. And (from memory) pdb and similar for Java unwind too much, before entering the debugger. 3. handler-bind and such cannot be functions (while otherwise retaining the same interface), because those forms affect the
10:47:03
_death
I think TMA is imagining an implementation that has a lambda-list-keyword-p function that checks a symbol's name.. then why provide a lambda-list-keywords list and not such a function to the user?
10:48:00
nij-
hayley - thanks: 1. In general we should prevent writing nonlocal codes. It makes me more curious why in some case we choose to use conditions/handlers instead of if/case.
10:48:46
nij-
hayley 2. What does "unwind" mean? What makes those languages unwind and lose too much info?
10:49:07
lisp123
and control flow for say _exceptional_ circumstances to flow through the condition system
10:49:23
hayley
Should we? Dynamic variables are the same sort of thing, that passing information through e.g. function arguments is cumbersome. Similarly handling situations "locally" can get cumbersome.
10:49:37
pjb
_death: the difference in information is: (let (lambda-list-keywords) (do-symbols (s) (if (lambda-list-keyword-p s) (push s lambda-list-keywords))) lambda-list-keywords)
10:49:38
nij-
hayley 3. Yeah, in general many things cannot be functions. So while macros are great, that's one of their limit, isn't it?
10:50:28
hayley
Unwinding means to abandon evaluation of some evaluation. What RETURN-FROM, THROW, etc do.
10:51:15
hayley
nij-: It's more a limit of functions at face value, that for a function application, all arguments are evaluated before the function is called, so a function has no control of how arguments are evaluated.
10:51:21
_death
pjb: the point is that you may want to write a program (say, a code walker) that has to deal with certain lambda list keywords.. if you then find a symbol that's a lambda list keyword that you don't handle, you can signal an error.. so if lambda-list-keywords is not exhaustive, it's not very useful
10:52:35
nij-
lisp123 why do we want the exceptional circ. to flow through the cond. system not if/case?
10:53:30
nij-
hayley: But macros, on the other hand, are not first class citizens. We can not apply things on them..
10:53:46
lisp123
nij-: because for errors or other exceptional situations, by cleanly segregating the code that handles the normal "business" case and the error case, it is easier to flow through a program and understand what it does
10:54:21
lisp123
you very much want to consider errors on their own and then the main program on its own and then at a combined level how the error protection helps make your program more robust (although jury is out on that one)
10:54:27
nij-
lisp123 ! I think that makes sense. Yeah, if I use if/case ordinarily, the main body will be crowded with exception handlings.
10:54:56
lisp123
but its good you are thinking about these things, because now you will be better at making that judgement on when to use what
10:54:56
hayley
Sure, they are not first class, but what you are asking for isn't well formed. FUNCALL and APPLY will be called with values that were produced by evaluating other forms. Macros process unevaluated forms.
10:57:35
hayley
Macro functions are functions, and thus in turn objects. But macros are used before evaluation (though the macro function is called, causing more evaluation), whereas functions are used in evaluation.
10:58:08
lisp123
its hard to understand macros vs functions as a beginner and then one day it clicks
10:58:41
lisp123
if you remember that macros are used to create new syntax, thats a good heuristic to guide you
10:59:01
nij-
I know that macros do not eval their args.. just curious what we can apply on macros meaningfully.
10:59:04
lisp123
i.e. if you have lots of code repeat or annoying function calls, a macro may be the answer
10:59:20
jackdaniel
it's simple, macros are expanded by the preprocessor, that's how we can define operators that accept any kind of arguments!
11:01:24
nij-
In C we cannot apply on functions.. and that's not too convenient. I'm trying to ask if such case is for macros too.
11:02:05
jackdaniel
nij-: you can't apply "on" a macro, because that would require evaluating the argument
11:02:58
jackdaniel
if that weren't the case, we could just (defmacro shmapply (the-macro list-to-be-shmapplied) `(the-macro ,@list-to-be-shmapplied))
11:04:06
_death
as an aside, cl-su-ai discussion threads http://cl-su-ai.lisp.se/msg02882.html and http://cl-su-ai.lisp.se/msg02879.html are quite interesting
11:06:37
jackdaniel
we are repeating the history with the speed of light; each cycle is slightly worse though ;)
11:25:12
beach
nij-: If you still have questions, maybe I can provide some perspective. Or did you have all your questions answered?
11:26:31
beach
nij-: What hayley said is right, but I am not sure you were satisfied with some of the answers.
11:34:26
pjb
nij-: or if you insist on apply/funcall, you can write: (funcall (macro-function 'cond) '(cond ((= x 1) 'hi) (t 'bye)) nil) #| --> (if (= x 1) (progn 'hi) (cond (t 'bye))) |#
11:36:09
_death
pjb: the discussion started with an ambiguity in the glossary definition of "lambda list keyword".. there were two competing interpretations and one of them implied that lambda-list-keywords could not be exhaustive
11:36:27
pjb
There are a few things that are not first class objects in CL: types, multiple-values, and I can think of nothing else right now.
11:37:18
pjb
_death: I see a single definition: lambda list keyword n. a symbol whose name begins with ampersand and that is specially recognized in a lambda list. Note that no standardized lambda list keyword is in the KEYWORD package.
11:42:29
pjb
_death: the only form that is not a macro definition that uses &-symbols is destructuring-bind!
11:43:11
pjb
_death: so if an implementation has additionnal special &-symbols specific to destructuring-bind lambda-lists, then indeed they won't be listed anywhere.
11:44:20
pjb
_death: but destructuring-bind lambda-list are defined with respect to macro lambda-lists: A destructuring lambda list can contain all of the lambda list keywords listed for macro lambda lists except for &environment, …
11:45:09
pjb
_death: so we can argue that any non-standard &-symbol used in destructuring-bind should be non-standard &-symbol used macro lambda-lists, and therefore should be in lambda-list-keywords.
11:45:47
pjb
_death: To have the lambda-lists keywords of destructuring-bind not be a subset of the lambda-lists keywords of macro, you'd have to have a language extension.
11:49:02
_death
pjb: you should pay attention to TMA's arguments.. I argued against that interpretation by a very mild form of reductio ad absurdum
11:49:52
pjb
_death: so I'd say that there's a problem with the standard, but happily implementations provide an exhaustive list in lambda-list-keywords.
11:50:17
_death
pjb: description of lambda-list-keywords doesn't restrict to defmacro.. it says the list should _also_ include those symbols
11:53:32
pjb
then lambda-list-keywords = A list of all the lambda list keywords used in the implementation. ; we can ignore the "including clause" since it's included!
11:54:45
pjb
Now since it's exhaustive, the glossary definition can be reduced to lambda list keyword = member of lambda-list-keywords.
11:55:15
pjb
Just adding somewhere the specification that (every (lambda (s) (aref (symbol-name s) 0) = #\&) lambda-list-keyword).
11:55:36
_death
[13:37] <TMA> it still keeps a bit of wiggle room for symbols that are recognized by the implementation but not used in it
11:56:10
pjb
Nope. I argue against that. Starting from the precise definition of lambda-list-keywords that you helped me understand.
12:05:44
_death
imagine if implementation used (defun rest-lambda-list-keyword-p (symbol) (string= symbol "&REST")) to recognize &rest, but only used cl:&rest itself.. then one interpretation is the glossary definition is satisfied, and a lambda-list-keywords list (that is not exhasutive, but contains cl:&rest) is still possible
12:06:04
nij-
pjb I didn't mean "apply macros", but "apply on macros". Something like (higher-order-op #'a-macro)
12:07:23
beach
nij-: Sure. I found your questions pertinent, but perhaps could use a more precise phrasing.
12:08:14
_death
pjb: my argument is that it would be strange to supply a CL user with lambda-list-keywords that's not exhaustive, and in that case a lambda-list-keyword-p function (that is exhaustive) would make more sense.. therefore the interpretation that has such undesirable consequences is unlikely to be the intended one
12:09:19
beach
nij-: That would be using a macro as a first-class object. You can use the "macro function" as a first-class object.
12:10:19
beach
nij-: So there is nothing special about using an object to "apply on" as you put it, compared to any other usages of an object.
12:12:21
beach
nij-: The thing about forms such as HANDLER-BIND is that they can not be functions because the forms in its scope must be evaluated in an environment that is not the same as the one that the form itself is evaluated in.
12:13:32
beach
nij-: I think your comparison between functions and macros in that respect is not justified.
12:14:15
beach
nij-: Maybe because you sometimes see names of macros as the first element of a compound form, you think they are like functions, so you want them to have the same possibilities.
12:15:02
nij-
Hmm.. I'd rather say I think both of them are objects, so should be transformable in meaningful or interesting ways.
12:19:05
beach
nij-: Again, I think you want macros to behave like functions because you see them used in similar-looking forms. But they are very different animals, just as numbers are different from functions, which is why I brought up numbers.
12:19:52
beach
nij-: When you define a macro, what really happens is (setf (macro-function <name>) (lambda (form environment) <the-body-of-the-macro>))
12:22:02
beach
nij-: I think you should stop wanting macros or macro functions to be like functions. Just like you don't seem to have any desire to have numbers behave like functions.
12:22:19
beach
nij-: They are different animals. Functions work at run time. Macros work at compile time.
12:23:23
nij-
I brought up this question because of one of phoe's writing, in 4.5.9 of his book "lack of functional interface for handler and restart"
12:23:56
nij-
It suggests that such lack is a drawback, making wonder if they were functions (ofc they cant be).. what would be different?
12:24:29
beach
nij-: I don't have in memory what he meant, but I am guessing that he meant something like how (SETF MACRO-FUNCTION) and MACRO-FUNCTION are the functional interface for macros.
12:25:27
hayley
I think phoe mentioned a lack of "introspection" functions for handlers in his OLM presentation.
12:26:38
nij-
4. (phoe) Are there any ready-to-use portable condition system that's based on CLOS ;) ?
12:26:55
beach
nij-: Sometimes, the standard specifies an underlying function interface to macros, like DEFUN is defined in terms of FDEFINITION and (SETF FDEFINITION). Sometimes it doesn't, like DEFTYPE does not have an underlying interface using functions.
12:28:31
nij-
Yeah I think what phoe meant in his book is that the standard one is not based on CLOS. And unfortunately in at least one popular implementation it's really not based on CLOS.
12:28:54
hayley
Bindings for restarts and handlers have dynamic extent still. Would one have, say, a CALL-WITH-RESTARTS function as a functional analog to RESTART-CASE?
12:30:45
beach
nij-: That might be for historical reasons and because of the way bootstrapping is done in must existing Common Lisp implementations.
12:31:17
nij-
beach I mean has someone written a portable condition system for Lisp that's based on CLOS
12:31:50
beach
nij-: I just don't know what "based on" means. Whether it somehow exposes CLOS to the user of it, or whether it is just implemented using it.
12:32:36
beach
nij-: In most Common Lisp implementations, CLOS is "bolted on" at the end. So if they want the condition system to work before that, they can't use CLOS to implement it.
12:33:57
hayley
(I remember I made a lazy attempt at updating Pitman's code before, but got bored of it quickly.)
12:34:56
jackdaniel
I don't know how about other implementations, but in ecl define-condition is defclass under the hood
12:35:29
jackdaniel
and make-condition is make-instance (after processing arguments to have the proper shape)
12:35:35
nij-
jackdaniel yeah I think he mentioned that most impls uses CLOS, but at least one popular impl doesnt
12:35:55
beach
nij-: The system written by phoe is basically what SICL uses natively. I made a few changes.
12:36:48
beach
nij-: What phoe wrote was not meant to be used natively, so I had to adapt it in a few ways.
12:38:21
beach
nij-: The point here is that the Common Lisp condition system is very simple. Once you have non-local control transfer in the form of CATCH/THROW, TAGBODY/GO, and BLOCK/RETURN-FROM, and macros, then you can write a complete condition system.
12:39:15
beach
nij-: This is why phoe has been arguing in favor of non-local control transfer in WASM. As opposed to including a complicated exception system in the language itself.
12:39:40
nij-
And is it correct to say that if one implements handler-bind, then all other relevant operators in C-S can be impl easily?
12:41:16
hayley
Note that due to https://www.plover.com/~mjd/misc/hbaker-archive/MetaCircular.html only one sort of non-local control transfer is necessary to produce the other two.
12:44:25
jackdaniel
re wasm, some changes are not introduced to it because of the current "stake holders" say that this would require too much work on their end;
12:45:11
jackdaniel
that said there is hope if microwasm is adopted (some runtimes already implement it), because it provides better primitives i.e to implement non-local control transfer
12:46:14
nij-
But this page gets me lost.. http://clhs.lisp.se/Body/d_specia.htm#special I'm no longer sure if that's merely the case.
12:46:53
dim
hi there! is Xach still around sometimes? The certificate for www.xach.com expired on 6/15/2022
12:53:36
pjb
_death: I explained that a predicate makes less sense than a list, because to collect the list, you need to do more work, and the predicate already knows the list! It's not like it was a property of the symbol, it's just an arbitrary set.
12:54:55
pjb
nij-: the point is that macro functions are functions like any other, there's no predicate to distinguish them. This is due to the fact, that there's no operator to get a function signature. Any function that takes a form (a proper list), and an environment can be used as a macro-function!
12:57:13
pjb
_death: we mentionned the need of a grammar for the additionnal keywords. sicl uses a parser that allows adding custom grammar rules for lambda-lists.
12:58:21
pjb
nij-: (mapcar (macro-function 'and) '((and t t) (and nil t) (and t nil) (and nil nil)) '(nil nil nil nil)) #| --> ((if t (and t)) (if nil (and t)) (if t (and nil)) (if nil (and nil))) |#
12:59:17
pjb
nij-: (mapcar (alexandria:compose #'eval (macro-function 'and)) '((and t t) (and nil t) (and t nil) (and nil nil)) '(nil nil nil nil)) #| --> (t nil nil nil) |# DUH!
15:24:27
jackdaniel
I'm playing with serializing and expanding protocols to code, here's McCLIM geometry substrate with extensions (the svg document is generated with McCLIM): http://turtleware.eu/static/paste/c5c3e822-proto.svg