Skip to content

Instantly share code, notes, and snippets.

@PuercoPop
Created August 26, 2015 14:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save PuercoPop/702886f80cddceb2211e to your computer and use it in GitHub Desktop.
Save PuercoPop/702886f80cddceb2211e to your computer and use it in GitHub Desktop.

Ok so a while back a ran into a problem when extending the slot options in CLOS. I went digging in SBCL and saw it uses a case based approach to process the slot arguments/options. The AMOP in page 95 shows a way to use the CLOS famework to 'teach' CLOS how to process custom options (for slots and classes) inserting a generic function to hook into called 'canonicalized-{defclass,slot}-option'. However due to bootstraping issues IIUC (which I probably don't) defgeneric isn't avaiable at the time that code is evaluated so that extension can't be included willy nilly in SBCL itself.** So it occured to me that maybe a CLOS implemented on top the implementations CLOS could provide a path of least resistance to continue improving the CLOS framework*.

* I use framework not in the software sense but in the general sense.

** A possiblity to extend SBCL for this case adding a "lookup in a hash-table case for a default case first" could be done but I would't recommend it.

@fare
Copy link

fare commented Aug 26, 2015

Or maybe, start by separating mechanisms and policy, and expose the parts necessary for JITting the code, while offering a usable protocol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment