public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* The Expression problem
@ 2022-08-29 21:35 daniel szmulewicz
  2022-08-29 22:11 ` Per Bothner
  0 siblings, 1 reply; 6+ messages in thread
From: daniel szmulewicz @ 2022-08-29 21:35 UTC (permalink / raw)
  To: kawa

Hi,

I was wondering what was Kawa's stance regarding the Expression problem,
ie. extending existing Java classes.
ABCL provides a mechanism to specialize on Java classes as documented in
section 4.5.2 of the user manual. Clojure provides defprotocol and defmulti
to extend existing types. I skimmed through the Kawa manual and am still
unsure. I am very curious to hear more from the experts.

Thank you.

Daniel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: The Expression problem
  2022-08-29 21:35 The Expression problem daniel szmulewicz
@ 2022-08-29 22:11 ` Per Bothner
  2022-08-30 18:24   ` daniel szmulewicz
  0 siblings, 1 reply; 6+ messages in thread
From: Per Bothner @ 2022-08-29 22:11 UTC (permalink / raw)
  To: daniel szmulewicz, kawa

On 8/29/22 14:35, daniel szmulewicz via Kawa wrote:

> I was wondering what was Kawa's stance regarding the Expression problem,
> ie. extending existing Java classes.
> ABCL provides a mechanism to specialize on Java classes as documented in
> section 4.5.2 of the user manual. Clojure provides defprotocol and defmulti
> to extend existing types. I skimmed through the Kawa manual and am still
> unsure. I am very curious to hear more from the experts.

You can definitely extend existing Java classes and inetrfaces.  See:

https://www.gnu.org/software/kawa/Defining-new-classes.html

True multiple inheritance is supported.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: The Expression problem
  2022-08-29 22:11 ` Per Bothner
@ 2022-08-30 18:24   ` daniel szmulewicz
  2022-08-30 18:57     ` Per Bothner
  0 siblings, 1 reply; 6+ messages in thread
From: daniel szmulewicz @ 2022-08-30 18:24 UTC (permalink / raw)
  To: kawa

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".
To quote from a paper
<https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.2323&rep=rep1&type=pdf>,
"the expression problem (aka the extensibility problem) refers to a
fundamental dilemma of programming: to which degree can your application be
structured in such a way that both the data model and the set of virtual
operations over it can be extended without the need to modify existing
code, without the need for code repetition and without runtime type errors."
Not all languages have viable solutions to the Expression problem. Clojure
and ABCL haved designs that address it, and I was wondering where Kawa is
positioned.

Kind regards, Daniel


On Tue, Aug 30, 2022 at 1:12 AM Per Bothner <per@bothner.com> wrote:

> On 8/29/22 14:35, daniel szmulewicz via Kawa wrote:
>
> > I was wondering what was Kawa's stance regarding the Expression problem,
> > ie. extending existing Java classes.
> > ABCL provides a mechanism to specialize on Java classes as documented in
> > section 4.5.2 of the user manual. Clojure provides defprotocol and
> defmulti
> > to extend existing types. I skimmed through the Kawa manual and am still
> > unsure. I am very curious to hear more from the experts.
>
> You can definitely extend existing Java classes and inetrfaces.  See:
>
> https://www.gnu.org/software/kawa/Defining-new-classes.html
>
> True multiple inheritance is supported.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: The Expression problem
  2022-08-30 18:24   ` daniel szmulewicz
@ 2022-08-30 18:57     ` Per Bothner
  2022-08-30 18:57       ` Per Bothner
  2022-08-31  7:13       ` Helmut Eller
  0 siblings, 2 replies; 6+ messages in thread
From: Per Bothner @ 2022-08-30 18:57 UTC (permalink / raw)
  To: kawa; +Cc: daniel szmulewicz

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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: The Expression problem
  2022-08-30 18:57     ` Per Bothner
@ 2022-08-30 18:57       ` Per Bothner
  2022-08-31  7:13       ` Helmut Eller
  1 sibling, 0 replies; 6+ messages in thread
From: Per Bothner @ 2022-08-30 18:57 UTC (permalink / raw)
  To: kawa

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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: The Expression problem
  2022-08-30 18:57     ` Per Bothner
  2022-08-30 18:57       ` Per Bothner
@ 2022-08-31  7:13       ` Helmut Eller
  1 sibling, 0 replies; 6+ messages in thread
From: Helmut Eller @ 2022-08-31  7:13 UTC (permalink / raw)
  To: kawa


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

I'm not sure what this has do with static name resolution specifically,
but I note that the Julia language seems to be somewhat successful
(ie. popular) with multi-methods that aren't all that different from
Common Lisp's generic functions.

It also seems me that the team behind the Fortress language tried pretty
hard to come up with a static type system for multi-methods.  They made
some progress, but in the end they failed.

I think that for Kawa a Julia-style approach would be "good enough".
Especially, as one can use Java interfaces in places where static typing
is a concern.

Helmut


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-08-31  7:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-29 21:35 The Expression problem daniel szmulewicz
2022-08-29 22:11 ` Per Bothner
2022-08-30 18:24   ` daniel szmulewicz
2022-08-30 18:57     ` Per Bothner
2022-08-30 18:57       ` Per Bothner
2022-08-31  7:13       ` Helmut Eller

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