On Wed, 9 Dec 2020 at 10:50, Jean-Claude Beaudoin < jean.claude.beaud...@gmail.com> wrote:
> > > On Wed, Dec 9, 2020 at 3:59 AM Alessio Stalla <alessiosta...@gmail.com> > wrote: > >> About multithreading, *all *kinds of redefinition have an impact. If I >> redefine a widely-used, low-level function, with hundreds of call sites – >> will each thread immediately call the new one without the bug, or will some >> still call the old one? Again, imposing a proper order would require >> protecting each function call with a lock, which is even worse for >> performance than protecting each slot access. >> > > Isn't "inline/not-inline" doing just what is needed in that area? > I'm talking about non inlined functions, for which the implementation may nevertheless have done type inference or other optimizations that could be invalidated by a redefinition. > > Still, we consider function redefinition a key feature of Common Lisp. So, >> redefinition of classes is in accordance with the spirit of the language. >> > > Redefinition of function is not "in situ". Why should redefinition of > classes have to be so? I am not advocating against class redefinition! > It is. We can redefine a function without having to track and recompile/redefine all uses of that function. In the simple case, it's just updating a pointer. But what if the compiler had performed cross-function optimizations? Or, what if the compiler *couldn't *perform such optimizations because they would have gotten in the way of redefinition? It's not just CLOS to have this issue – it's the whole of Common Lisp.