public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: kawa@sourceware.org
Cc: daniel szmulewicz <daniel.szmulewicz@gmail.com>
Subject: Re: The Expression problem
Date: Tue, 30 Aug 2022 11:57:03 -0700	[thread overview]
Message-ID: <d744ae3b-cdf5-67a4-3f31-f4c254ffa4a0@bothner.com> (raw)
In-Reply-To: <CAABPU69g-Qb4EUopv2TT3crN93+V1=vf7sE15D4iPU5c3-0oBQ@mail.gmail.com>

On 8/30/22 11:24, daniel szmulewicz via Kawa wrote:
> Thank you for the prompt response. This reference indeed tells me how to
> create new classes or extend existing classes. However, I was interested in
> a way to add functionality without touching existing code. For example,
> make all instances on the java.lang.String class respond to `foo`, as in
> (foo "a string") -> "bar".

I think of "extending a class" as "creating a new class that extends an
existing class".  You're asking for something a little different, which I
would call "multi-methods".  Common Lisp calls them "generic functions"
(using "generic" in a different way than Java does).  Common Lisp also
differs from Java-style classes in that CL "methods" do not "belong" to
a class, which allows for more flexibility.

Kaws does have some support for "generic functions":
https://www.gnu.org/software/kawa/Generic-procedures.html

I don't remember if the "Warning" accurately describes the current state of Kawa
and method resolution.  You can certainly solve "the Expression problem"
if you provide the methods to make-procedure in proper order (most-specific
to least-specific).  I think there is a mechanism to automatically sort
by specificity, but I don't remember - it's been a long time.

I think Common Lisp generics are problematic if you have a module system
(or library system to use R7RS terminology) based on static name resolution.
CL generics assume a generic function is global, and as each module is loaded
it dynamically adds methods to the generic procedure.  This is powerful,
but seems contrary to modern module system.  I've thought a bit about how best to
specify multi-methods in a more disciplined way.  It's not an easy problem.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

WARNING: multiple messages have this Message-ID
From: Per Bothner <per@bothner.com>
To: kawa@sourceware.org
Subject: Re: The Expression problem
Date: Tue, 30 Aug 2022 11:57:03 -0700	[thread overview]
Message-ID: <d744ae3b-cdf5-67a4-3f31-f4c254ffa4a0@bothner.com> (raw)
Message-ID: <20220830185703.8HvBkVk2RdR6_YK0TJaEf9F9GUteeAnA_-eSCS0NoOs@z> (raw)
In-Reply-To: <CAABPU69g-Qb4EUopv2TT3crN93+V1=vf7sE15D4iPU5c3-0oBQ@mail.gmail.com>

On 8/30/22 11:24, daniel szmulewicz via Kawa wrote:
> Thank you for the prompt response. This reference indeed tells me how to
> create new classes or extend existing classes. However, I was interested in
> a way to add functionality without touching existing code. For example,
> make all instances on the java.lang.String class respond to `foo`, as in
> (foo "a string") -> "bar".

I think of "extending a class" as "creating a new class that extends an
existing class".  You're asking for something a little different, which I
would call "multi-methods".  Common Lisp calls them "generic functions"
(using "generic" in a different way than Java does).  Common Lisp also
differs from Java-style classes in that CL "methods" do not "belong" to
a class, which allows for more flexibility.

Kaws does have some support for "generic functions":
https://www.gnu.org/software/kawa/Generic-procedures.html

I don't remember if the "Warning" accurately describes the current state of Kawa
and method resolution.  You can certainly solve "the Expression problem"
if you provide the methods to make-procedure in proper order (most-specific
to least-specific).  I think there is a mechanism to automatically sort
by specificity, but I don't remember - it's been a long time.

I think Common Lisp generics are problematic if you have a module system
(or library system to use R7RS terminology) based on static name resolution.
CL generics assume a generic function is global, and as each module is loaded
it dynamically adds methods to the generic procedure.  This is powerful,
but seems contrary to modern module system.  I've thought a bit about how best to
specify multi-methods in a more disciplined way.  It's not an easy problem.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

  parent reply	other threads:[~2022-08-30 18:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29 21:35 daniel szmulewicz
2022-08-29 21:35 ` daniel szmulewicz
2022-08-29 22:11 ` Per Bothner
2022-08-30 18:24   ` daniel szmulewicz
2022-08-30 18:24     ` daniel szmulewicz
2022-08-30 18:57     ` Per Bothner [this message]
2022-08-30 18:57       ` Per Bothner
2022-08-31  7:13       ` Helmut Eller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d744ae3b-cdf5-67a4-3f31-f4c254ffa4a0@bothner.com \
    --to=per@bothner.com \
    --cc=daniel.szmulewicz@gmail.com \
    --cc=kawa@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).