freenode/lisp - IRC Chatlog
Search
19:29:32
phoe
22.1.3.3.1 says, When the symbol is printed, if it is in the KEYWORD package, then it is printed with a preceding colon; otherwise, if it is accessible in the current package, it is printed without any package prefix; otherwise, it is printed with a package prefix.
19:30:50
phoe
A symbol that is apparently uninterned is printed preceded by ``#:'' if *print-gensym* is true and printer escaping is enabled; if *print-gensym* is false or printer escaping is disabled, then the symbol is printed without a prefix, as if it were in the current package.
19:30:58
phoe
the part "if *print-gensym* is false or printer escaping is disabled, then the symbol is printed without a prefix, as if it were in the current package. "
19:31:13
phoe
does "the symbol" mean the symbol being printed, or that gensym that was just mentioned
19:32:29
phoe
since I think it means the gensym that was just mentioned, being on the same paragraph and all
19:33:47
Bike
none of that stuff should matter. the second sentence of 22.1.3.3 says the rest of the section doesn't apply unless printer escaping is enabled
19:34:31
phoe
why the hell does the test require that a symbol read with standard IO syntax be in CL-TEST package and not in CL-USER
19:36:35
Bike
like i said, i don't see anything saying the structure class name is necessarily printed with the prefix.
19:38:34
kpoeck
My last input: In 22.1.3.3 Printing Symbols it says ...The remainder of Section 22.1.3.3 applies only when printer escaping is enabled
19:40:16
Bike
well, i don't know, it might be ok to print the prefix for the structure class name, i just don't see anything saying it HAS to
19:41:53
kpoeck
so for me the solution is to change the test to: (assert (or (eq (car vals) 'print-struct-1) (eq (car vals) 'cl-user::'print-struct-1)))
19:43:12
kpoeck
(assert (or (eq (car vals) 'print-struct-1) (eq (car vals) 'cl-user::print-struct-1)))
19:58:44
kpoeck
(let ((symbol (car vals))) (assert (and (string-equal (symbol-name (car vals)) "print-struct-1") (or (eql (symbol-package symbol) (find-package :cl-user)) (eql (symbol-package symbol)(find-package :cl-test))))))
5:15:35
no-defun-allowed
I looked at https://irclog.tymoon.eu/freenode/%23lisp?from=2018-11-26T00%3A14%3A11&to=2019-11-26T12%3A14%3A11&search=Lisp%20System%20Implementation&by#
5:22:04
anlsh
Thanks! Seems like the discussion hasn't been extensive, so I'll have to try to catch beach sometime
5:34:25
ebrasca
aeth: I have installed sbcl on my talos II, but I can't make it work with multithreading.
6:13:45
aeth
I think no-defun-allowed was also involved in the discussion iirc and no-defun-allowed knows the threading libraries.
6:15:21
aeth
me niether, but the benchmark would be simple. 1 thread, n threads (where n is number of cores), n*2 threads, n*4 threads (because power has 4-way SMT)
6:20:03
beach
anlsh: A lot of the book contains C code, and the strategy for implementing memory allocation is very different from what most implementations would do.
6:20:48
beach
I had hoped that it would discuss pros and cons with different implementation strategies, but it is basically just the code of one particular implementation.
6:25:09
anlsh
I see. As to the "too much C" complaint, were you hoping the author would bootstrap earlier?
6:26:17
beach
Well, I was hoping for an insight into different strategies. Among them, a strategy where everything is written in Common Lisp, and the pros and cons of that one.
6:27:39
beach
The title of the book suggested that. But, like I said, it is basically just the commented code of one particular implementation.
6:32:00
beach
anlsh: If the goal is to create a general-purpose Common Lisp implementation, today there is no particular reason to write it in a language other than Common Lisp.
6:33:49
anlsh
Thanks, I think you're right in that we're trying to get different things from the book. Follow-up, how much experience did you have with the topics in the book beforehand? I don't have any experience with compilers, and am wondering how approachable it would be
6:34:42
beach
I think it is fairly easy to understand. But it doesn't give any insight into different ways of creating a Common Lisp system.
6:35:35
beach
I am writing SICL at the moment, so I already have experience with different implementation strategies.
6:36:25
beach
anlsh: You would learn more about the pros and cons of different strategies by asking in #sicl than by reading that book.
6:36:42
anlsh
Yeah, my interest it is definitely from a different perspective. I was hoping to use it as an introduction to language implementation in general
6:37:58
beach
But if you don't have too many budget restrictions, go ahead and buy it just to check it out.
6:41:25
anlsh
Well, if it's not usable as an intro text to implementation stuff then I'll hold off for now
6:42:11
beach
Sure. Again, if you want to discuss different strategies, go ahead and do it here or in #sicl.
6:48:15
beach
anlsh: For example, most existing implementations were started before CLOS was part of the standard, so they all incorporate CLOS very late in the build process. I think that with a new implementation, that strategy is not a good one.
6:49:12
beach
Even SBCL suffers from that problem. The compiler is written without the use of generic functions.
6:53:01
beach
For instance, SICL can use DEFCLASS to define the class SYMBOL, but if you don't have CLOS, you have to define it differently.