[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)