<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-05-19 8:41 GMT+02:00 Robert Smith <span dir="ltr"><<a href="mailto:quad@symbo1ics.com" target="_blank">quad@symbo1ics.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>I am absolutely boggled by this attitude. This is an issue that one runs into when writing Common Lisp code, and not an issue that one runs into writing in another language and associated ecosystem. To me, that's a Lisp problem. We can do some creative academic definitions, I think, but it's a problem when choosing Lisp as a tool.</div><div></div></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">The problem is not a Lisp problem.  It occurs in many language ecosystems, and it cannot generally be solved.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Things are relatively simple if you just look from the top to the bottom, from the usage of a lower-level library by a higher level library or application functionality.  Such usage could confined to within that tree of a linked application, e.g. by symbol or package renaming or the like, and similar techniques have been tried (in Lisp, but also in JVM languages and most likely elsewhere).</div><div class="gmail_extra"><br></div><div class="gmail_extra">The real issue though is data types defined by versioned libraries.  Suppose that an instance of a data type defined in library A version 1 is passed, through higher levels of the software, to version 2 of that same library.  How would one ever expect that to work?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Faré is completely right:  There is no way to apply some external magic to a hairball of different library versions of libraries and expect the result to work.  The only way to deal with it is to actually address the conflicting versions and make sure that all libraries in a system are prepared to use the same overall set of dependencies.  If a tool can help with detecting conflicts, it is great, and maybe that is what would be a good goal in the CL world to create such a tool and version tagging infrastructure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I can report that in the Clojure world, every conference that I visited has at least a lightening talk on the subject of library versions and how to deal with them.  I have yet to see one where the presenter claims to have a solution, and most of these talks end up concluding that there is a possible problem which cannot generally be solved, but that many Clojure shops get away ignoring the problem.  We have been using the leiningen build tool to help us finding library version conflicts and generally strive towards smaller systems to reduce the number of dependencies that we need to synchronize, version-wise.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Hans</div></div>