Hi Tomas,

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