Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Current" solution for generalized set!
> My first reaction is that it seems extremely intrusive on the whole Scheme
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. On the language
level, we have removed the table which maps procedures to setters. We
also avoid associating a setter slot with each procedure. Instead, we
create a new type of procedures which contain the getter and setter.
> b) avoids all this crud with adding slots to closures and other intrusive
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. I can tell you 1. that it won't
slow down the application of an ordinary closure one single
nanosecond, and 2. that it *probably* won't affect creation of
closures enough to be noticeable. This is a matter that we will
examine before adding this code, though.
> But I'll think more about it. Maybe there is some beauty there that I'm too
> thick to see :-)
You're welcome to raise arguments against modifying `set!' at all, but
the current suggestion is definitely better than "plain old dynamic
It's a bit sad that I'm the only one that previously tried to protect
the simplicity of the language.
Guile Home |
Main Index |