#lisp - Sat 3 Mar 2007 between 00:00 and 00:10

bdowningnowhere_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.)
astorone 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.
bdowningThe 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.
astorand 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.)
I can't believe I said "one's". Shoot me.
nowhere_manastor: I'm wondering if dont-follow markers would be needed
cpstbdowning: I think it's a solvable problem, but that people don't care that much about it
nowhere_mancpst: that's also my (rather uninformed) opinion
bdowningcpst: Quite possible. It'd be great to see better stuff out there.
astornowhere_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_manbut if INTERN is not reachable from the entry point...
cpstdead 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?)
hefnera more realistic solution is to use a smaller lisp system.
cpstof course when you start including the printer, and read macros, you get into tricky territory
nowhere_mancpst: I don't see where it should become tricky
cpstbut given all of the other magic SBCL does, it shouldn't be hard in comparison
nyefcpst: Feel free to implement something, then.
nowhere_mancpst: it's just that much more things become theoretically reachable, so you just can't safely toss much out
cpstnyef: I've done similar things in toy compilers
nyefcpst: So?
astornowhere_man: hmm. I guess a symbol knows what package it refers to and thus reaches all functions in that package.
cpstI 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_manastor: if symbols are implemented as an object just including it's name, maybe not
bdowningI'm failing to see how it should be simultaneously easy and even moderately effective, given the metacircularity of your average Lisp system.
nowhere_mancpst: 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 ;-)
cpstnowhere: the biggest problem will be in the metacircularity
astornowhere_man: that would mean that symbol-package would have to be implemented using a hash-table.
cpstnowhere: you'd need to have flags that disable certain features in the included parts of the implementation
astornowhere_man: and that would hurt people that want to refer to symbol-package.

Page: 2 9 16 23 30