@screwlisp

Good point, but what exactly is javascriptifying, please?

@vnikolov
So I wrote Hurkle in lisp the other day, as I kept talking about.

However, my new blog uses my friend Aral's #kitten web framework, whose host language is javascript. To Aral's chagrin, I have no intention of learning javascript.

But my friend mnl originally wrote a macro package called parenscript:

HURKLE/PS> (ps
(let ((foo 'bar))
(values foo)))
"(function () {
var foo = 'bar';
return foo;
})();"

Allows host javascript written in lisp
https://screwlisp.small-web.org/lispgames/itching-for-hurkles/

@vnikolov
oops I meant:

HURKLE/PS> (ps
(let ((foo 'bar))
(lambda () (values foo))))
"(function () {
var foo = 'bar';
return function () {
return foo;
};
})();"

confusingly, it's just that Kitten's host language is javascript in this case- I want my Hurkle game to show a dynamically generated static page using a local cookie. So writing lisp that writes javascript that writes dynamically generated static html. I think it's a reasonable step towards my hurkle.

@vnikolov
(defun close-over-board (&optional (rows 10) (cols 10))
(let
((board (loop :repeat rows
:collect
(loop :repeat cols
:collect
"?")))
(hurkle-r-c (list (random rows) (random cols))))
(lambda ()
(with-html-string
(:table
(loop :for row :in board
:collect
(:tr
(loop :for col :in row :collect (:td) ))))))))

I guess I had to rewrite my hurkle game without using CLOS. I thought a bit about using the 'make-load-form generic

@screwlisp

> had to rewrite my hurkle game without using CLOS. I thought a bit about using the 'make-load-form generic

Embarrassingly, my memory fails now about what exactly happened to standardizing anonymous generic functions.

#CLOS
#CommonLisp

@vnikolov

I don't quite follow the connection between Hurkle and anonymous generic functions here, but this got me wondering, in general, what are some good uses for them?

So far I can't think of a great use. I'm assuming you mean the ability to create GFs on the fly and add methods to them, right?

@screwlisp

@sigue @screwlisp

P.S.
Maybe my guess was completely off.
In any case, if Parenscript can handle the make-load-form machinery, that seems like it would be a huge accomplishment.

@vnikolov @sigue
Did I link https://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ld_.htm before? This is the hyperspec page with an extended example use. MAKE-LOAD-FORM-SAVING-SLOTS provides low-level internal convenience useful for constructing your own object's MAKE-LOAD-FORM method.

My point above was that a non-class-based closure's FUNCTION-LAMBDA-EXPRESSION can simply be thrown into parenscript to generate a javascript equivalent, but parenscript obviously doesn't have its own CLOS implementation.

[CLOS and JavaScript]

@screwlisp @sigue

> parenscript obviously doesn't have its own CLOS implementation

And achieving that doesn't seem like a five-minute job...

I am not the judge of whether that work can be justified, no matter how attractive it is.

#CLOS
#CommonLisp
#JavaScript
#Parenscript

[Red Daly's Parenscript Object System, simplified-CLOS-like.]

@abuseofnotation @screwlisp @sigue

Thank you, that is impressive.
From Stanford.
Regrettably, I don't have the time to find out the extent of simplification.

#CLOS
#CommonLisp
#JavaScript
#Parenscript

@dougmerritt @abuseofnotation @screwlisp @sigue

> since it came up, how many CLOS features do you need?

You are right to ask.
Off the top of my head, I've needed
multiple inheritance,
multiple dispatch,
"before" and "after" methods.
Maybe I did something with method combination once or twice, but let's not count this if I can't recall properly.
But I am not a serious ("heavy-duty") #CLOS user.

If this counts, in other languages I have missed capabilities to customize object initialization.

@vnikolov
@dougmerritt @abuseofnotation @screwlisp

> "before" and "after" methods

I think the core feature is call-next-method, which can effectively be used to simulate around/before/after? (Not 100% sure it's an exact match.)

The main difference seems to be in the ability to define the before/after/around behavior separately, as opposed to combining it into one method definition.

(Why am I saying this? I tend to look at CL through the eyes of a Dylan hacker and so I had to wonder "Do I actually miss combined methods?" Not really, because I have next-method.)

@sigue @vnikolov @dougmerritt @abuseofnotation @screwlisp

Speaking of which, is there 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?

Or is it just not needed?

(Most of my CLOS experience was with the Symbolics version, which of course had such a thing.)

@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.

#CLOS
#CommonLisp

@vnikolov @sigue @dougmerritt @abuseofnotation @screwlisp

Dylan has such a thing, with "sealed" classes/methods/etc.

In CL, and in Symbolics CL, you could always redefine things later at runtime. In that case, a combined method (:BEFORE daemons, main method, :AFTER daemons -- ignoring wrappers and whoppers) would be redefined and dynamically recompiled.

compile-flavor-methods was often the last thing in a system's source files, so the compiler would emit code for the combined methods. Otherwise they'd have to be built on first call, which would make applications sluggish when first loaded.

Now CLOS may have different needs, if it doesn't have :BEFORE/:AFTER daemons or wrappers (which are kind of like macros, generating code that needs compilation).

(call-next-method) is a procedural way to do this, costing an extra function call at runtime, but obviating the need for weird compilation.

Obligatory joke: we used to call combined methods (:BEFORE/main/:AFTER) "the fruit of the immaculate compilation" since there was nothing directly corresponding to them in the source.

It was funny at the time.

Sort of.

@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.

#CLOS
#CommonLisp

@vnikolov @weekend_editor @sigue @abuseofnotation @screwlisp
It just occurred to me that no one else has been mentioning (so far as I've noticed) "The Art of the Metaobject Protocol", Kiczales, Rivieres, Bobrow, 1991, so I will.

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol

Maybe it's just me, but when I read it, it seemed ultra-deep, like something I could spend years on, yet I was uncertain that the topic deserved such a deep analysis -- maybe I'd be more happy with a shallow, easy-to-grasp analysis.

Alan Kay called it "the best book anybody's written in ten years".

Edit: and went on: and contended that it contained "some of the most profound insights, and the most practical insights about OOP", but was dismayed that it was written in a highly Lisp-centric and CLOS-specific fashion, calling it "a hard book for most people to read; if you don't know the Lisp culture, it's very hard to read".[4][5]

What say you all?

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol

P.S. And whatever happened to Portable CLOS?

https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/pcl/0.html

@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.)

#AMOP
#CLOS
#CommonLisp

@weekend_editor
Oops! Your phrasing reminds me that you *did* mention it, if only in passing, which is no doubt what prompted my subconscious to think about it.

https://mathstodon.xyz/@vnikolov@ieji.de/114631874473328951

I don't suppose you have a substantive comment thereon? I suppose I'm wondering if it would pay off for me to re-read it.

@sigue @abuseofnotation @screwlisp