5 ms·

> Tree shakers are not written because they ‘are cool’ Yeah this is all very serious business. Also, one of the most curmudgeonly responses you could have give

by gaze 7y ago

> Tree shakers are not written because they ‘are cool’ Yeah this is all very serious business. Also, one of the most curmudgeonly responses you could have given. > #sbcl is not THE Common Lisp community This is not my sample size of one opinion. I’m just throwing one in the pot for the very widely held opinion of the Common Lisp community being curmudgeonly.

lispm 7y ago
> Yeah this is all very serious business It's work and SBCL is maintained mostly by volunteers, who may have their own agenda. Sometimes there is funding from commercial projects. So far maintaining a treeshaker wasn't high on the agenda, even though the project runs for some years now. If you shell out serious money for your 'very serious business' the commercial implementations Allegro CL and LispWorks provide maintained tree shakers and all kinds of fancy application delivery features. > throwing one in the pot not very motivating... You might check out the link I've gave you above, instead.
- gaze 7y ago
  I may not have made myself clear. I don’t want someone else to write a tree shaker for me, I want an intro project to understanding the internals of a performant Common Lisp compiler, and I want to do the work to write a tree shaker myself. I’ve seen a few implementations, but they all come with notes explaining that they’re sketchy and experimental. I mostly wanted to know how to push them past that point into being robust.
  - dreamcompiler 7y ago
    Tree shakers require that you look at every function-bound symbol and determine if that symbol appears in the call graph of the main function(s) or in an isolated call graph. The functions that follow the call graph exist in most Common Lisps but they are not standardized; they're implementation-dependent. That's part of the reason tree shakers aren't widespread. Another reason is that if you're using the compiler in your runtime, even isolated parts of the call graph can still be useful, so tree shaking becomes something of a policy decision rather than a pure algorithm.
    - lispm 7y ago
      It's also not that easy, given one can cross the data is code frontier easily: (let ((fs '(+ - *))) (mapcar (lambda (f) (funcall f 1 2)) fs)) How do we know that the functions in FS can't be removed? They are just symbols in a list in the code.
      - dreamcompiler 7y ago
        Exactly. That's what I was getting at but your example is better because the compiler isn't really even being used at runtime here.
      - gaze 7y ago
        Yeah that’s super tricky... how does LispWorks deal with such things?
    - gaze 7y ago
      I have the impression that lispworks gets the gc to do the tree shaker's work http://www.lispworks.com/documentation/lw50/DV/html/deluser-52.htm http://www.lispworks.com/documentation/lw50/DV/html/deluser-...
      - lispm 7y ago
        Treeshaking is a separate phase during 'delivery' (aka creating an optimized application/library): it may use the GC in the treeshaking phase: http://www.lispworks.com/documentation/lw71/DV/html/delivery-22.htm#marker-859840 http://www.lispworks.com/documentation/lw71/DV/html/delivery...
    - dreamcompiler 7y ago
      ...and just as a follow-up, once you've dug into the problem enough to discover it's surprisingly difficult to define what is "the right thing" for a tree-shaker in Lisp to do, you realize that even if you build it, it doesn't buy you much. That's why we tend to sound curmudgeonly about the issue. It's a valuable learning exercise, so feel free to dig in. You'll gain some valuable insights into what makes Lisp special.
  - lispm 7y ago
    Hmm, the usual treeshaker might not tell you much about the internals of the compiler itself (a compiler is just one part of a Lisp system based on runtime, interpreter, various libraries, etc.), since the ones I've seen work over already compiled code. It's an interesting project, but not that easy for a complex piece of software like SBCL - depending on what the goals are.

by gaze 7y ago

lispm 7y ago

> Yeah this is all very serious business It's work and SBCL is maintained mostly by volunteers, who may have their own agenda. Sometimes there is funding from commercial projects. So far maintaining a treeshaker wasn't high on the agenda, even though the project runs for some years now. If you shell out serious money for your 'very serious business' the commercial implementations Allegro CL and LispWorks provide maintained tree shakers and all kinds of fancy application delivery features. > throwing one in the pot not very motivating... You might check out the link I've gave you above, instead.

gaze 7y ago
I may not have made myself clear. I don’t want someone else to write a tree shaker for me, I want an intro project to understanding the internals of a performant Common Lisp compiler, and I want to do the work to write a tree shaker myself. I’ve seen a few implementations, but they all come with notes explaining that they’re sketchy and experimental. I mostly wanted to know how to push them past that point into being robust.
- dreamcompiler 7y ago
  Tree shakers require that you look at every function-bound symbol and determine if that symbol appears in the call graph of the main function(s) or in an isolated call graph. The functions that follow the call graph exist in most Common Lisps but they are not standardized; they're implementation-dependent. That's part of the reason tree shakers aren't widespread. Another reason is that if you're using the compiler in your runtime, even isolated parts of the call graph can still be useful, so tree shaking becomes something of a policy decision rather than a pure algorithm.
  - lispm 7y ago
    It's also not that easy, given one can cross the data is code frontier easily: (let ((fs '(+ - *))) (mapcar (lambda (f) (funcall f 1 2)) fs)) How do we know that the functions in FS can't be removed? They are just symbols in a list in the code.
    - dreamcompiler 7y ago
      Exactly. That's what I was getting at but your example is better because the compiler isn't really even being used at runtime here.
    - gaze 7y ago
      Yeah that’s super tricky... how does LispWorks deal with such things?
  - gaze 7y ago
    I have the impression that lispworks gets the gc to do the tree shaker's work http://www.lispworks.com/documentation/lw50/DV/html/deluser-52.htm http://www.lispworks.com/documentation/lw50/DV/html/deluser-...
    - lispm 7y ago
      Treeshaking is a separate phase during 'delivery' (aka creating an optimized application/library): it may use the GC in the treeshaking phase: http://www.lispworks.com/documentation/lw71/DV/html/delivery-22.htm#marker-859840 http://www.lispworks.com/documentation/lw71/DV/html/delivery...
  - dreamcompiler 7y ago
    ...and just as a follow-up, once you've dug into the problem enough to discover it's surprisingly difficult to define what is "the right thing" for a tree-shaker in Lisp to do, you realize that even if you build it, it doesn't buy you much. That's why we tend to sound curmudgeonly about the issue. It's a valuable learning exercise, so feel free to dig in. You'll gain some valuable insights into what makes Lisp special.
- lispm 7y ago
  Hmm, the usual treeshaker might not tell you much about the internals of the compiler itself (a compiler is just one part of a Lisp system based on runtime, interpreter, various libraries, etc.), since the ones I've seen work over already compiled code. It's an interesting project, but not that easy for a complex piece of software like SBCL - depending on what the goals are.