#clos — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #clos, aggregated by home.social.
-
@chiffchaff @oxy @davidgerard This is eerily evocative of the current monoculture in modern networking: #eBGP , #Clos network (spine-and-leaf), aggregated top-of-rack switches. #STP everywhere. Mentioning #G8032 #ERPS rings gets you strange looks; that's just for security camera #PoE switches isn't it? /s And the utter dependency of #SRv6 #TILFA robustness on #ISIS state. From this I infer that the #GenAI obsession is retarding actual progress in telecoms and computer networking.
-
@chiffchaff @oxy @davidgerard This is eerily evocative of the current monoculture in modern networking: #eBGP , #Clos network (spine-and-leaf), aggregated top-of-rack switches. #STP everywhere. Mentioning #G8032 #ERPS rings gets you strange looks; that's just for security camera #PoE switches isn't it? /s And the utter dependency of #SRv6 #TILFA robustness on #ISIS state. From this I infer that the #GenAI obsession is retarding actual progress in telecoms and computer networking.
-
@chiffchaff @oxy @davidgerard This is eerily evocative of the current monoculture in modern networking: #eBGP , #Clos network (spine-and-leaf), aggregated top-of-rack switches. #STP everywhere. Mentioning #G8032 #ERPS rings gets you strange looks; that's just for security camera #PoE switches isn't it? /s And the utter dependency of #SRv6 #TILFA robustness on #ISIS state. From this I infer that the #GenAI obsession is retarding actual progress in telecoms and computer networking.
-
@chiffchaff @oxy @davidgerard This is eerily evocative of the current monoculture in modern networking: #eBGP , #Clos network (spine-and-leaf), aggregated top-of-rack switches. #STP everywhere. Mentioning #G8032 #ERPS rings gets you strange looks; that's just for security camera #PoE switches isn't it? /s And the utter dependency of #SRv6 #TILFA robustness on #ISIS state. From this I infer that the #GenAI obsession is retarding actual progress in telecoms and computer networking.
-
@chiffchaff @oxy @davidgerard This is eerily evocative of the current monoculture in modern networking: #eBGP , #Clos network (spine-and-leaf), aggregated top-of-rack switches. #STP everywhere. Mentioning #G8032 #ERPS rings gets you strange looks; that's just for security camera #PoE switches isn't it? /s And the utter dependency of #SRv6 #TILFA robustness on #ISIS state. From this I infer that the #GenAI obsession is retarding actual progress in telecoms and computer networking.
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
https://www.europesays.com/fr/877644/ Dinan Léhon-Bordeaux : le XI de départ des Girondins avec Léo Jousselin #avec #Bordeaux #clos #comptant #coup #depart #devoiler #Dinan #donné #envoi #equipe #face #football #FR #France #Gastel #Girondins #journee #Jousselin #Lehon #Mavuba #national #pour #rencontre #sera #Sports #Stade #vient
-
https://www.europesays.com/afrique/46411/ un huis clos tragique sur la chape patriarcale en Tunisie #2026 #chape #Cinéma #clos #CritiquesDeFilms #culture #huis #patriarcale #silentium #tragique #Tunisie
-
For my research into building better abstractions, I'm looking at #CommonLisp, and, in particular, #CLOS, the extremely flexible and powerful #OO system that is part of the language. It is probably as powerful as any OO language in existence, given that some of the internal mechanisms can be altered to better fit your problem space. According to the Art of the Metaobject Protocol, CLOS doesn't occupy a point the space of possible OO systems, but a region.
-
For my research into building better abstractions, I'm looking at #CommonLisp, and, in particular, #CLOS, the extremely flexible and powerful #OO system that is part of the language. It is probably as powerful as any OO language in existence, given that some of the internal mechanisms can be altered to better fit your problem space. According to the Art of the Metaobject Protocol, CLOS doesn't occupy a point the space of possible OO systems, but a region.
-
For my research into building better abstractions, I'm looking at #CommonLisp, and, in particular, #CLOS, the extremely flexible and powerful #OO system that is part of the language. It is probably as powerful as any OO language in existence, given that some of the internal mechanisms can be altered to better fit your problem space. According to the Art of the Metaobject Protocol, CLOS doesn't occupy a point the space of possible OO systems, but a region.
-
For my research into building better abstractions, I'm looking at #CommonLisp, and, in particular, #CLOS, the extremely flexible and powerful #OO system that is part of the language. It is probably as powerful as any OO language in existence, given that some of the internal mechanisms can be altered to better fit your problem space. According to the Art of the Metaobject Protocol, CLOS doesn't occupy a point the space of possible OO systems, but a region.
-
<">
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 -
<">
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 -
<">
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 -
N2 : Les Girondins de Bordeaux risquent de jouer à huis clos !
© Iconsport Les Girondins de Bordeaux de nouveau sanctionnés pour l’usage de fumigènes Les Girondins de Bordeaux menacés…
#Bordeaux #FR #France #Actu #News #Europe #EU #actu #Actualités #clos #club #europe #fumigenes #Girondins #huis #jouer #match #NouvelleAquitaine #Républiquefrançaise #revocation #risquent #sanctionné #suite #Supporters #sursis #usage
https://www.europesays.com/fr/461112/ -
https://www.europesays.com/fr/461112/ N2 : Les Girondins de Bordeaux risquent de jouer à huis clos ! #actu #Actualités #Bordeaux #clos #club #EU #europe #FR #France #fumigenes #Girondins #huis #jouer #match #News #NouvelleAquitaine #RépubliqueFrançaise #revocation #risquent #sanctionné #suite #Supporters #sursis #usage
-
Le film Scurry raconte une histoire d’extraterrestres https://tozounoir.zouluvo.com/le-film-scurry-raconte-une-histoire-dextraterrestres/
#film #Scurry #alien #araignée #géante #invasion #extraterrestre #tunnel #soussol #suspense #acteurs #effets #spéciaux #créature #huis #clos #sciencefiction #peur #tension #horreur #captivant #mystérieux #sombre #attaque #ville #monstre #souterrain #cinéma #ambiance #extraterrestres
-
Le film Scurry raconte une histoire d’extraterrestres https://tozounoir.zouluvo.com/le-film-scurry-raconte-une-histoire-dextraterrestres/
#film #Scurry #alien #araignée #géante #invasion #extraterrestre #tunnel #soussol #suspense #acteurs #effets #spéciaux #créature #huis #clos #sciencefiction #peur #tension #horreur #captivant #mystérieux #sombre #attaque #ville #monstre #souterrain #cinéma #ambiance #extraterrestres
-
Le film Scurry raconte une histoire d’extraterrestres https://tozounoir.zouluvo.com/le-film-scurry-raconte-une-histoire-dextraterrestres/
#film #Scurry #alien #araignée #géante #invasion #extraterrestre #tunnel #soussol #suspense #acteurs #effets #spéciaux #créature #huis #clos #sciencefiction #peur #tension #horreur #captivant #mystérieux #sombre #attaque #ville #monstre #souterrain #cinéma #ambiance #extraterrestres
-
Cl-gopher is a Common Lisp library that implements the server and client sides of the Gopher protocol, as well as a sample text client. An easy to understand and well designed example of using CLOS.
-
Cl-gopher is a Common Lisp library that implements the server and client sides of the Gopher protocol, as well as a sample text client. An easy to understand and well designed example of using CLOS.
-
Cl-gopher is a Common Lisp library that implements the server and client sides of the Gopher protocol, as well as a sample text client. An easy to understand and well designed example of using CLOS.
-
Bordeaux-Colomiers : les Girondins tenus en échec
© Iconsport Le 11 de la première période marquée National 2 : Hoekstra – Grillot (c) – Vandenabeele –…
#Bordeaux #FR #France #Actu #News #Europe #EU #actu #Actualités #clos #Colomiers #dispute #echec #europe #face #Girondins #huis #juillet #leur #match #mercredi #NouvelleAquitaine #preparation #Républiquefrançaise #tenus
https://www.europesays.com/fr/285139/ -
https://www.europesays.com/fr/285139/ Bordeaux-Colomiers : les Girondins tenus en échec #actu #Actualités #Bordeaux #clos #Colomiers #dispute #echec #EU #europe #face #FR #France #Girondins #huis #juillet #leur #match #mercredi #News #NouvelleAquitaine #preparation #RépubliqueFrançaise #tenus
-
Bordeaux-Colomiers : le 11 des Girondins de la première mi-temps
© Iconsport L’équipe évoluera avec trois défenseurs centraux, deux milieux, des pistons, et 3 attaquants : 343. Le…
#Bordeaux #FR #France #Actu #News #Europe #EU #actu #Actualités #Bruno #clos #Colomiers #Decouvrez #depart #europe #face #Girondins #Haillan #huis #Irles #jouent #leur #match #mercredi #NouvelleAquitaine #première #preparation #Républiquefrançaise #temps
https://www.europesays.com/fr/284513/ -
https://www.europesays.com/fr/284513/ Bordeaux-Colomiers : le 11 des Girondins de la première mi-temps #actu #Actualités #Bordeaux #Bruno #clos #Colomiers #Decouvrez #depart #EU #europe #face #FR #France #Girondins #Haillan #huis #Irles #jouent #leur #match #mercredi #News #NouvelleAquitaine #première #preparation #RépubliqueFrançaise #temps
-
https://www.europesays.com/fr/283959/ Girondins : match face à l’US Colomiers (N3) à 17h #affrontent #Bordeaux #clos #Colomiers #diffusee #face #football #FR #France #Girondins #Haillan #huis #joue #juillet #match #mercredi #Plaine #rencontre #Sports
-
[AMOP]
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlispRight now I'm thinking that the real value of _The Art of the Metaobject Protocol_ is showing one way to do metaprogramming, and object-oriented programming is merely a demonstration domain.
Of course, what begat AMOP was a desire for an approach that can cover a large part of the OOP language design space, not just one point in that space, in order to be attractive to different schools of thought.
-
[AMOP]
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlispRight now I'm thinking that the real value of _The Art of the Metaobject Protocol_ is showing one way to do metaprogramming, and object-oriented programming is merely a demonstration domain.
Of course, what begat AMOP was a desire for an approach that can cover a large part of the OOP language design space, not just one point in that space, in order to be attractive to different schools of thought.
-
[AMOP]
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlispRight now I'm thinking that the real value of _The Art of the Metaobject Protocol_ is showing one way to do metaprogramming, and object-oriented programming is merely a demonstration domain.
Of course, what begat AMOP was a desire for an approach that can cover a large part of the OOP language design space, not just one point in that space, in order to be attractive to different schools of thought.
-
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlisp
> no one else has been mentioning (so far as I've noticed) "The Art of the Metaobject Protocol"
Not in this thread.
Indeed, this book is a tour de force (et de magique).> uncertain that the topic deserved such a deep analysis
The topic—maybe, maybe not, but the book is really about the metatopic, i.e. about metaprogramming, if I may abuse this prefix.
(I know this ought to be formulated more carefully.) -
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlisp
> no one else has been mentioning (so far as I've noticed) "The Art of the Metaobject Protocol"
Not in this thread.
Indeed, this book is a tour de force (et de magique).> uncertain that the topic deserved such a deep analysis
The topic—maybe, maybe not, but the book is really about the metatopic, i.e. about metaprogramming, if I may abuse this prefix.
(I know this ought to be formulated more carefully.) -
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlisp
> no one else has been mentioning (so far as I've noticed) "The Art of the Metaobject Protocol"
Not in this thread.
Indeed, this book is a tour de force (et de magique).> uncertain that the topic deserved such a deep analysis
The topic—maybe, maybe not, but the book is really about the metatopic, i.e. about metaprogramming, if I may abuse this prefix.
(I know this ought to be formulated more carefully.) -
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> (call-next-method) is a procedural way to do this, costing an extra function call at runtime, but obviating the need for weird compilation.
And that is the costs-of-lisp-implementation consideration.
The other one is the program design consideration (including the costs of program modification), which often leads me to prefer a declarative style, but that is my point of view, there are always tradeoffs, etc.
-
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> (call-next-method) is a procedural way to do this, costing an extra function call at runtime, but obviating the need for weird compilation.
And that is the costs-of-lisp-implementation consideration.
The other one is the program design consideration (including the costs of program modification), which often leads me to prefer a declarative style, but that is my point of view, there are always tradeoffs, etc.
-
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> (call-next-method) is a procedural way to do this, costing an extra function call at runtime, but obviating the need for weird compilation.
And that is the costs-of-lisp-implementation consideration.
The other one is the program design consideration (including the costs of program modification), which often leads me to prefer a declarative style, but that is my point of view, there are always tradeoffs, etc.
-
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
P.S.
If I recall correctly, freezing a set of class and generic function definitions (including the methods) precludes some operations later, like redefining a class at run time, but I don't know if this is related to your question.
Again, don't trust me. -
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
P.S.
If I recall correctly, freezing a set of class and generic function definitions (including the methods) precludes some operations later, like redefining a class at run time, but I don't know if this is related to your question.
Again, don't trust me. -
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
P.S.
If I recall correctly, freezing a set of class and generic function definitions (including the methods) precludes some operations later, like redefining a class at run time, but I don't know if this is related to your question.
Again, don't trust me. -
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> a CLOS equivalent to (compile-flavor-methods), that compiles all those combined methods so they don't have to be done at load or run time?
Not in the (full¹) CLOS specification.
Speaking from uncertain memory, check it if it's important.
_________
¹ Including the parts not in the ANSI standard.I have a very vague and insufficient memory of a non-Flavors implementation that provides something like that.