Re: "Current" solution for generalized set!

[Chris.Bitmead@misys.com.au]

>> My first reaction is that it seems extremely intrusive on the whole
Scheme >
>>system.
>
>If you use the "plain old dynamic dispatch set!" as a reference it is
>quite the opposite.
>
>What we've done is to limit the constraints which a compiler has to
>deal with so that it still will be able to do inlining.  We have also
>made the changes on the language level more local.

Help me to understand, because the idea of conceptually inheriting from the
procedure type for this purpose seems strange to me.

This is how I understand it. In Scheme now there are a number of functions
which do different things depending on type. Let's take (display) for
example. In a Scheme that compiled to C, maybe display would be inlined
something like this...
dispatch_table[scm->type]->display(scm);

I can't see that it could be inlined beyond this because we don't know the
run-time type.

Similarly, I would have thought a set! could be inlined as
dispatch_table[scm->type]->set(scm, value);

It's not obvious to me how the idea of instead changing the procedure
object is "more local". A "plain dynamic dispatch set!" would be re-using
an idea already in the language.

>On the language
>level, we have removed the table which maps procedures to setters.

But what I don't get is why we want to map procedures to setters at all.
Surely
what we want to do is map types to setters. After all it is going to be the
 type
of the object we are trying to set a member of which determines which
setter to use.

I must be missing something big here.

> We
>also avoid associating a setter slot with each procedure.

But who really wants to associate setter slots with procedures? Don't we
want to
associate procedures with object types?

>Note that this is the current choice of *internal* representation.  A
>user will never see the setter slot.  The setter slot is not
>accessible in an ordinary closure.  So it is no problem.
>
>If the implementors choose to use this internal representation, it is
>probably because it is efficient.
>
>You're welcome to raise arguments against modifying `set!' at all, but
>the current suggestion is definitely better than "plain old dynamic
dispatch set!".
>
>It's a bit sad that I'm the only one that previously tried to protect
>the simplicity of the language.

I think it's more a case of everyone having a different idea of what
protecting the simplicity of the language actually means.

My concern is not that your idea is or isn't efficient. It is that the
whole design
seems to rely on being able to modify the guts of the system in order to be
able
to implement efficiently. If I were to take some arbitrary R5RS Scheme, and
without
modifying it try to implement this scheme, I would need some ugly form of
table
lookup or something (I think). At least if I had a version of Scheme with
some clean
dynamic dispatch generic function system, a plain dynamic set! should just
slot into the scheme of things.

I'm sure you know what you're doing, but being the curious type I'd like to
understand this better.