| bdowning | nowhere_man: Basically that inside your implementation's code everything ties together at some point, so you just need to state "drop the compiler" and "drop the pretty-printer" and check that nothing breaks. (Something usually broke for me.) |
| astor | one possible way of pruning stuff like symbol tables can be to have a root set of objects, and a dont-follow set which includes stuff like symbol tables. and you don't trace past a dont-follow object to find live objects. |
| bdowning | The fact that none of the commercial implementations have "magic" tree-shakers that don't require setting lots of options and trial-and-error hacking indicates to me that the problem space has not been solved, and is probably not trivial. |
| astor | and then if you have good tools that can pinpoint why you need something then it should be easier to be fairly certain whether you can remove it. |
| bdowning | (At least, none of the one's I've seen.) gah I can't believe I said "one's". Shoot me. |
| nowhere_man | astor: I'm wondering if dont-follow markers would be needed |
| cpst | bdowning: I think it's a solvable problem, but that people don't care that much about it (unfortunately) |
| nowhere_man | cpst: that's also my (rather uninformed) opinion |
| bdowning | cpst: Quite possible. It'd be great to see better stuff out there. |
| astor | nowhere_man: well, if you intern a symbol you refer to the hash-table of your package and then you refer to all functions in your package as an example. |
| nowhere_man | but if INTERN is not reachable from the entry point... |
| cpst | dead code elimination is a pretty well understood optimization, and here we are using a pretty well understood terrible approximation of a call graph (is it even referenced anywhere?) |
| hefner | a more realistic solution is to use a smaller lisp system. |
| cpst | of course when you start including the printer, and read macros, you get into tricky territory |
| nowhere_man | cpst: I don't see where it should become tricky |
| cpst | but given all of the other magic SBCL does, it shouldn't be hard in comparison |
| nyef | cpst: Feel free to implement something, then. |
| nowhere_man | cpst: it's just that much more things become theoretically reachable, so you just can't safely toss much out |
| cpst | nyef: I've done similar things in toy compilers ;) |
| nyef | cpst: So? |
| astor | nowhere_man: hmm. I guess a symbol knows what package it refers to and thus reaches all functions in that package. |
| cpst | I am just saying that it shouldn't be so hard but CL people are like Smalltalk people, they like to live in their "image" |
| nowhere_man | astor: if symbols are implemented as an object just including it's name, maybe not |
| bdowning | I'm failing to see how it should be simultaneously easy and even moderately effective, given the metacircularity of your average Lisp system. |
| nowhere_man | cpst: commercial implementations have some incentives to be able to ship light binaries so I wouldn't bet too fast that it's easy doable, I think not excessively hard but hard work, still the base will surely be really easy, maybe trivial then you get all the corner cases ;-) |
| cpst | nowhere: the biggest problem will be in the metacircularity |
| astor | nowhere_man: that would mean that symbol-package would have to be implemented using a hash-table. |
| cpst | nowhere: you'd need to have flags that disable certain features in the included parts of the implementation |
| astor | nowhere_man: and that would hurt people that want to refer to symbol-package. |