<">
I mean, typecase using type specifiers makes sense, it’s a type-based operation after all. But handler-bind feels like a class- (or whatever the hierarchy of conditions are, they are not standard-objects iirc) based operation. Yet it uses type specifiers, and that’s a fun turn of events.
</">

My intuition is different.
I see this part of what `handler-bind' does merely (or at least essentially) as a kind of type dispatch (except that the primitive types are only condition types).

(Whether condition types are standard-classes is implementation-dependent, so they may or may not be such.
What is important is that the hierarchy of the kinds of conditions is integrated with the hierarchy of classes (and types).)

<">
I wish generics also allowed type specifiers. Imagine the world we’d be living in…
</">

To some degree I think we already do.
I haven't done this, so off the top of my head, I think it's possible to base method dispatch on (much of) what compound type specifiers allow by sufficiently heavy use of the Meta-Object Protocol and suitable metaclasses.
It would likely be also necessary to wrap `defmethod' in macro calls, but that is par for the course.

Whether that would be a good idea is another matter.
The complexity of the implementation would have to be justified.
Then this might reduce the efficiency of method dispatch.
(We usually don't mind when the efficiency of handling exceptional situations is less than the efficiency of "regular" execution.)

#CLOS
#CommonLisp
#CommonLispObjectSystem
#GenericDispatch
#MetaObjectProtocol
#MOP

@aartaka

<"/>
I found [it] interesting since it says their approach should have wide applicability.

And very rightly so:
both
that you should find it interesting
and
that the approach should have wide applicability.

Just making my opinion explicit, not that present or absent company needs me to know that 🙂.

#AMOP
#MetaObjectProtocol

@dougmerritt

<"/>
"Metaobject protocols: Why we want them and what else they can do"
Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow
... 1993

Excellent catch.

#AMOP
#MetaObjectProtocol

@dougmerritt

#commonLisp #programming #amop #mop #metaobjectProtocol #exercise #closette #learnToCode (my own experience) #oop
https://screwlisp.small-web.org/amop/eg1/

Today I simply share and solve (hopefully!) The Art of the Metaobject Protocol exercise 1.1

(the softball generic classes #memoization exercise from chapter 1)

I just added a lexical closure of hash tables.

@simoninireland wrote about the art of the metaobject protocol in his #lisp bibliography a year ago. https://simondobson.org/2024/07/23/the-art-of-the-metaobject-protocol/

Art of the metaobject protocol Exercise 1.1: Memoize Closette apply-generic-function

> I shortened Jim des Rivieres to Rivieres. Is this correct, or am I meant to write des Rivieres?

I would keep "des" and more importantly I would check what the already established practice for citing this name is in the literature.
That would also include keeping the accent (des Rivières).

#AMOP
#CommonLisp
#MetaobjectProtocol

@screwlisp

[Applying the Metaobject Protocol.]

Needless to say, if you not only read that book, but also put it to use, you will learn a lot and that is priceless.

What you describe seems like a suitable problem to apply the MOP to and to get a grasp of it.
Good hunting!

#AMOP
#CommonLisp
#MetaobjectProtocol
#MOP

@screwlisp @dougmerritt

@thatgeoguy The #PrettyPrint dispatch table of #CommonLisp is conceptually a #GenericFunction with parametric dispatch, altough not formalized as such and not a formal part of the Common Lisp Object System (CLOS).

However, it is possibly to extend #CLOS for #ParametricDispatch using the #MetaObjectProtocol (#MOP).

The Metaobject Protocol is not part of the formal CL standard, but is respected as de-facto standard, since about every CL implementation will stick to it. The protocol is described in The Art of the Meta-Object Protocol by Gregor Kiczales, Jim des Rivieres and Daniel G. Bobrow.

🌺

🦎 https://t.me/FamilyOfLisp

🏷️ #Lisp #Scheme
CLHS: Section 22.2.1.4