Thank you for your feedback. Answers below.
On Fri, Nov 22, 2024 at 12:46 PM Tomas Volf <~@
wolfsden.cz> wrote:
I do find the symmetry between define-method/define-method* and
define/define* pleasing.
Yes, I guess we are free to form GOOPS in our own style regardless of CLOS.
For define and define*, one could argue that procedures produced by the
latter are slower to call (I did measure). Is that an issue here as
well?
Well, the implementation in my patch essentially does the same amount of work as the old one, and when not using keywords a call is as efficient. Generic function dispatch should be unaffected, as with Marks macro. However, there will be the same kind of overhead as for define* in calls actually using keywords.
I checked what the optimizer can do with the resulting method when using Marks elegant macro. Unfortunately, such a method would have overhead. However, I do think that a modified version of Marks macro together with a small change in peval could have a chance not to introduce such overhead.
All, in all, it currently (and paradoxically) turns out to be simpler to provide the keyword functionality in define-method rather than also providing define-method* if one doesn't want to introduce overhead for the most common types of methods.
Perhaps I could try to learn what is going on in peval and see if a macro similar to Marks would be the most elegant way to go forward.
You did mention backwards compatibility, but how serious you expect the
issue would be? I personally did not use GOOPS yet, but I have a hard
time imagining a real-world code that would be broken by this change.
Do you expect there would actually be any?
I said "backwards compatibility perspective" and was too lazy to spell out what I meant, which is this: Assume that we *now* want to write backwards compatible code. Then, if we have *not* modified define-method we can be certain that as long as we use define-method, we will be backwards compatible. However, if we introduce keywords in define-method (rather than define-method*) this is no longer true. If this new functionality is confined to define-method*, then a future code can test for the presence of defined-method* in Guile and otherwise provide something similar to Marks (or Anders Vinjars from April 2003 :-)) macro.
I personally would probably lean towards two separate procedures (mainly
due to the assumption of there being a performance impact).
Well, there is none now that we have Andys remarkable compiler. Now also Janneke has responded and he prefers to have everything in define-method. Myself, I'm split. I can see merits in both solutions. Least code bloat would probably be to just apply my patch. But I think we should think mostly about style (where I am still split).
Best regards,
Mikael
Have a nice day,
Tomas Volf
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.