Re: setf.scm

[Chris.Bitmead@misys.com.au]

>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 don't personally see multi-methods as violating functional
priciples. Sure, when you declare a multi-method you must change
a global dispatcher. But once the program is already running,
functional principles prevail.

>I can add a new class to a running system without changing any
>of the objects (classes or instances) already existing.

Yes, but think of the alternative *In a situation where you need
multi-methods*. Instead of the change to objects already existing
being virtually theoretical (creating a new multi-method), you
may have to actually go and change the existing code.

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

As I said, don't see this as making things functionally impure,
because a running system does not change things.

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

Sounds a bit academic. Any time you add a class to an already
existing hierarchy, you are going to have to change the code
somewhere in order to create new instances of that class. Creation
can't be dispatched. Therefore in this situation you absolutely
must change the state of already existing parts of the system.

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

I think if a language allows you to succinctly express exactly what
you want to do, then it fits the above properties.

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

New methods too??? Even in the single dispatch case, if you add
a method to a class, it will change the behaviour of classes that
use that class.

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

I think you are thinking too hard in terms of C style linkers. ld
was only ever very good as a C linker. It's not even very good as
a C++ linker. Many programming languages would be well served by
not imagining that everything must be determined at linking time
in the C fashion.

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

The people who designed Scheme didn't do so with even the slightest
care towards static analysis. That is the style of the language.
Any static analysis you can do in Scheme is pure bonus value. Nobody
should design things in Scheme with static analysis as a first
priority. In certain languages - yes, but Scheme's style is to
be completely dynamic. If you want static, go with ML.