Re: setf.scm

[Per Bothner <bothner@cygnus.com>]

> As for your modularity argument, you're still thinking of generic
> functions as belonging to some class.

No.  I'm thinking that the fact that methods in single-dispatch are
associated with some class is an advantage of single-dispatch.

I understand how to model single-dispatch in a state-less manner:
An object has a bunch of fields and methods associated with it.
The association is created when the object is created - i.e.
there is no need for side-effects to understand or implement this.
Calling a method is just a matter of selecting the right method
from the object using a key given by the call.
I can add a new class to a running system without changing any
of the objects (classes or instances) already existing.

I like these properties.  This is simple, easy to understand,
easy to implement, and the semantics are clean.  There are
no funny side-effects such as would be unsuitable for a
pure functional language.  Scheme is of course an impure
functional language, but I do want to keep the impure parts
of the language from the functional core of the language.
I specifically want to keep it away from apply and method
dispatch.

Perhaps it is possible to keep these properties in a language
with multi-dispatch, but I don't know how.  I'd love for
someone to point me at how to do it.  (Does Cecil multi-dispatch
coms closer?)

> It is no trouble at all for me to restrict access to generic functions
> through a package/module system

That is not the issue.  The issue is access to the methods, not the
generic functions.  I am concerned that one can add new methods
to a running system and have the behavior of calls change, even
when all the parameters involved predate the new methods.  You
might think this is a feature;  I don't.  (Of course being able to
modify a running system is useful, but there is an important
distinction between adding to a system vs modifying existing
code in it.)

> there's no sense in restricting the system for those of us who
> want the extra flexibility if there's little or no cost for it.

Flexibility is fine;  the question is:  does it allow you to write
better programs (shorter, more efficient, more maintainable, more
correct)?  If not, then the cost is major.  (My main concern is
not implementation efficiency, let me emphasize.)

>    Per> * I'm nervous about a "mostly-functional" language whose
>    Per> semantics depend so much on global state and side-effects.
>
> What, the MOP?

No, more how adding new methods and classes can change the behavior
of pre-existing objects.

Note, I see separate compilation as very important.  The operation
of linking should be one of combining different "modules"; if
linking requires re-arranging method precence tables at the
drop of a hat make me very nervous.  This is related to the
goal static analysis;  if you can only make meaningful
statements about whole programs, but not modules, then
I don't think it is very interesting.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner