freenode/#lisp - IRC Chatlog
Search
4:24:59
beach
I can't help wondering why jmercouris is interested in the subject, yet hasn't watched my presentations "Creating a Common Lisp implementation". :)
4:27:07
beach
phoe's description of a compiler is not quite true for Common Lisp, as I explain in those videos. A C compiler starts with an empty global environment (which is why there are all those #include things) whereas a Common Lisp compiler essentially needs a running Common Lisp system.
4:32:45
PlusEffect
I think I figured out how to compile SBCL on my Chromebook! Just had to comment out some tests that were not relevant on my platform.
4:32:47
aeth
A lot of general compiler stuff doesn't quite fit with CL. Especially the huge focus in most compilers on parsing.
4:34:46
beach
Yes, most compiler books have a large part about parsing. That's why I use Muchnick's book most of the time.
4:34:58
Bike
modern (since, i don't know, several decades) optimizing compilers have lots of their own theory of course
4:35:11
no-defun-allowed
I thought most of the compiler complexity was in IR, and only crappy interpreter tutorials take far too long on parsing -- oh, okay.
4:35:15
PlusEffect
It fails stat.2 and stat.4, I think, because I'm probably using those security modules that are mentioned in the comments. The root directory appearing writable to others somehow?
4:35:24
Bike
no, i mean, the actual complexity of an optimizing compiler is definitely the optimizing part, yes.
4:35:50
no-defun-allowed
My favourite coauthor had to write a "compiler" from whatever language (call this one Foo) to JS, and it was very much Foo source -> Foo AST -> JavaScript source
4:36:32
aeth
no-defun-allowed: An introduction to compilers, e.g. online or in a book, could be 50% or more about parsing... but obviously the optimization part is how you turn a 5 week compiler project into an infinite week compiler project.
4:37:45
beach
It used to be the case that parsing was a large part of the time a compiler took, probably because not many optimizations were performed. So parsing technology became a big deal.
4:38:32
no-defun-allowed
I wish they'd just provide e.g a YACC file, and get the damn thing over with, but there's also the tendency to stretch the material out by introducing one construct, then the grammar, then the evaluation rules, etc. But I'm not bored enough to rant about random stuff I read on the Internet again.
4:40:10
aeth
I really don't know how any individuals get past the parser part. It's time consuming. Even Scheme-in-CL took me a while and it's Scheme. In CL.
4:41:23
no-defun-allowed
I was going to say that someone actually wrote 41 thousand words on writing an interpreter without an evaluator, but they had in fact written an interpreter, and it was hidden by all the crap on parsing.
4:42:38
no-defun-allowed
aeth: Depending on your definition of parsing, doesn't C++ parsing range between annoying and not context free and outright undecidable? I got away with writing a few dispatch characters to fake Scheme syntax ([, ], #t and #f) though.
4:43:52
no-defun-allowed
There was a lot of bikeshedding there on writing the parser without a generator, yes.
4:45:12
no-defun-allowed
OpenCL gives you ulong (in place of unsigned long) and friends, possibly so they don't have to write unsigned long4 for the vector type.
4:45:57
dbotton
Why does (merge-pathnames #P"/Users/dbotton/common-lisp/clog/static-files/" "/tutorial/tut-11.html") results in the tutorial portion of the path disappearing ie => #P"/Users/dbotton/common-lisp/clog/static-files/tut-11.html"
4:47:44
no-defun-allowed
merge-pathnames doesn't really join paths together, from my reading of the CLHS: "Constructs a pathname from pathname by filling in any unsupplied components with the corresponding values from default-pathname and default-version."
4:49:20
no-defun-allowed
This begs the question of what function joins paths together, but in this case, you might be better served by ASDF:SYSTEM-RELATIVE-PATHNAME.
4:50:35
no-defun-allowed
e.g (asdf:system-relative-pathname :netfarm "bunnies.asc") on my system returns #P"/home/hayley/netfarm-projects/netfarm/Code/bunnies.asc". You could use something like (asdf:system-relative-pathname :clog "static-files/tutorial/tut-11.html") perhaps.
5:01:45
aeth
maybe this? (uiop:merge-pathnames* (make-pathname :directory `(:absolute "foo" "bar" "baz")) "whatever.html")
5:03:05
dbotton
That would mean I would have to tell users of my api to convert their path's to lists..
5:04:17
no-defun-allowed
That call to MAKE-PATHNAME will return in #P"/foo/bar/baz/", which isn't really helpful in any case.
5:05:01
aeth
no-defun-allowed: well, you'd , or ,@ depending on the problem but it seems like it doesn't give the API that dbotton wants
5:17:34
aeth
I think I'm going to update something in some of my code that solves the problem, but not with uiop:subpathname, so probably not as robustly
5:23:04
dbotton
I wouldn't have noticed it in mine if had not by chance tried merge-pathnames with a subdirectory following the file to merge on
12:19:31
VincentVega
Just got meself (gensym) to return two #:G0's nearly in a row. Thinking it has something to do with that reproducability rationale that I read about in one of the sbcl bugs. Currently working out a minimal example (which is proving to be a tad tricky), any insights would be appreciated...
12:26:40
VincentVega
Interesting. Can't say I really understand this bug to say for sure that this is the same one at this point, but yeah, it does look like it got the same roots. Thanks for the link.
12:28:20
phoe
well, you could try going to #sbcl and post your problem, maybe also link this issue if it's related
12:35:22
heisig
I recently promised I would start a collection of 'Common Lisp tweaks'. Well, here it is: https://github.com/marcoheisig/common-lisp-tweaks
12:36:55
heisig
I intend to grow this list whenever I hear about a new trick on IRC, so newcomers won't have to dig through decades of IRC logs to find them.
13:51:54
jmercouris
One thing I’ve been thinking about is that a defmethod is like a guard for a function call
14:16:00
jmercouris
I had been asking about the unique set of basic operators about a year ago i think
14:16:15
jmercouris
At the time I couldn’t articulate what I was trying to describe, but that is it!
14:17:45
beach
The paper by Baker is good. He explains various ways of implementing Common Lisp special operators using other Common Lisp special operators, and often the other way around too.
14:19:03
jmercouris
One thing that I think about a lot is maybe it would have been better if the default was doubly linked lists in lisp
14:20:04
beach
jmercouris: That would break almost every aspect of the semantics of large parts of Common Lisp.
14:21:14
heisig
If you are smart, every operation on lists is already O(1). And singly-linked lists help create beautiful recursive programs.
14:23:39
jmercouris
I think there are some algorithms that would be simpler to write with doubly linked lists
14:24:12
beach
jmercouris: If you have (defparameter *l0* (list 'a 'b 'c ...)) then (defparameter *l1* (cons 1 *l0*)) and (defparameter *l2* (cons 2 *l0*)), would then (rest *l1*) and (rest *l2*) be EQ with doubly linked lists?
14:25:28
heisig
jmercouris: Insertion at the front is O(1). Removal from the front is O(1). All you have to do is turn the list the right way round.
14:26:20
nij
Has anyone thought of making "notes" on discussion on #lisp, as the conversation here has been logged.
14:26:47
nij
Namely, now we are discussing why singly-linked list is the default. Maybe there could be a way to add a summary quickly that refers to this part of conversation?
14:28:41
beach
nij: While there are a few subjects with recurring questions, singly-linked vs doubly-linked lists as the default in Lisp is not one of them.
14:28:54
heisig
jmercouris: As for looking behind - if you only need to look a fixed number of list elements behind you, you an scan the list and keep track of the last K elements you just visited.
15:48:53
Josh_2
When using formatter, what do I pass as the stream arg to have it output as a string?
15:57:20
pfdietz
I had a situation that looked like (format nil (if <form> <string1> <string2>) ...), which I think runs faster if the IF parts were strength reduced with calls to formatter.