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