[HN Gopher] Depending in Common Lisp
       ___________________________________________________________________
        
       Depending in Common Lisp
        
       Author : Tomte
       Score  : 71 points
       Date   : 2022-08-26 16:13 UTC (6 hours ago)
        
 (HTM) web link (stevelosh.com)
 (TXT) w3m dump (stevelosh.com)
        
       | phoe-krk wrote:
       | _> Portable programs must not define methods on SHARED-
       | INITIALIZE._
       | 
       | TIL about this constraint and that it's only in effect when
       | initializing classes. I think that I understood it once I thought
       | about it for a moment.
       | 
       | It's possible that implementations have some of their internal
       | code in primary methods for INITIALIZE-INSTANCE, REINITIALIZE-
       | INSTANCE, UPDATE-INSTANCE-FOR-REDEFINED-CLASS, or UPDATE-
       | INSTANCE-FOR-DIFFERENT-CLASS (The Four Horsemen of SHARED-
       | INITIALIZE, if I may).
       | 
       | If the user supplies a method on SHARED-INITIALIZE, then it's
       | possible for this method to run between the system-provided
       | primary method on e.g. INITIALIZE-INSTANCE and the system-
       | provided method on SHARED-INITIALIZE. If this happens, the user-
       | provided method cannot depend on the object being in any
       | meaningful state: the system-provided method on INITIALIZE-
       | INSTANCE may leave the object in some sort of half-initialized
       | state, with the system-provided method on SHARED-INITIALIZE being
       | meant to finish the initialization. You don't want your code to
       | go in between these two.
       | 
       | Hell, the MOP authors had a _lot_ of foresight. (And experience,
       | I guess.)
        
         | gjvc wrote:
         | _Hell, the MOP authors had a lot of foresight. (And experience,
         | I guess.)_
         | 
         | https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...
         | is such a good read if you are seeking to stretch your mind :-)
        
       | vindarel wrote:
       | Here's a famous post by the author, more for the "general
       | public": https://stevelosh.com/blog/2018/08/a-road-to-common-
       | lisp/
       | 
       | (that I complement with the last news:
       | https://news.ycombinator.com/item?id=31646794)
        
       | whartung wrote:
       | The novelty here is that the bulk of this is about the image
       | nature of Common Lisp. The fundamental meta-class is all well and
       | good and interesting, but this is about defining, and REdefining
       | these structures in a living CL image and coping with the changes
       | in place.
       | 
       | In contrast to most other systems, where the static build is
       | simply that -- static. As a user, you don't have to worry so much
       | about this. Not that it's not possible in other systems, it most
       | certainly is. Other systems have very dynamic object structures.
       | But they're typically bound within a "build and relaunch the
       | world" metaphor of routine complete reset versus the "molding a
       | live image" of the CL workflow.
        
         | jlarocco wrote:
         | Sorry, but I disagree. It's not about the "image nature" of CL
         | (which, btw, is a very outdated way of using CL), but the
         | interactive nature of CL. They're similar, in that a Lisp REPL
         | has a memory image, but a running program in any language has a
         | memory image.
         | 
         | Python, Ruby, Haskell, or any language with a REPL can
         | experience this same problem, only in those languages there's
         | not a good way to handle it.
         | 
         | Edit: To expand a little more, the "image nature" of CL has
         | historically referred to dumping the in memory image to disk,
         | quitting, and then loading that image back into memory later
         | when the program starts again, and that's really an orthogonal
         | concept to what TFA is talking about.
        
       ___________________________________________________________________
       (page generated 2022-08-26 23:00 UTC)