This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setf.scm


Maciej Stachowiak <mstachow@MIT.EDU> writes:

> I think it would be useful to have setf! in the Guile core anyway even
> if this change were made, but a dynamic one. setf! is useful for many
> things.

Firstly, I'd like to thank you for forcing me to think.  I was anxious
to arrive at a solution quickly, so that Goops could get its
accessors, so that we could release Goops sooner (and so that I could
get some research done...!).  This made me treat this setf! issue too
sloppily.

As long as I could fool me into believeing that it was OK for setf! to
be a syntactic form, I had no problem with it.  My setf! was only
"syntactic sugar" for other standard Scheme language constructs,

But now you've convinced me that it is unschemey for setf! and setter
to be syntactic forms.  The "new" setf! is essentially a new language
mechanism, and you want guile-core to support it.

I have no problem with adding library procedures such as sort to the
guile-core distribution.  The idea in Scheme is to have a small core
language and get power from large libraries.  sort can be put away in
such a library, to be loaded only by users who need it.

I have no problem with setf! being distributed separately as a Guile
library, but I do have problems both with adding support for setf! in
the evaluator and with distributing it in guile-core.

setf! is a language mechanism.  Guile is a language, which is likely
to become some kind of de facto standard, at least in a limited sense.
Distributing setf! with guile-core implicitly means that we regard it
as a part of the Guile language.  But this conflicts with the goal to
keep the core language small.

Notice the difference between distributing a set of procedure
libraries with core Guile, and distributing new language mechanisms.
The latter makes Guile programs less portable and increases the
complexity of the language.  Why should we have a new type of binding
between procedures objects when we can manage without it?  As long as
fset! could be understood in terms of set!, the "cognitive footprint"
of the language was the same, but adding this new complexity also
seems unschemey to me.

Jim has set up general guide-lines for Guile development.  They
include the ability to support separate compilation of modules into
efficient code.

The new setf! creates problems in this respect.  It is supposed to
represent a very elementary operation: storing a value into a
location.  It should be possible for the compiler to reduce it to the
corresponding simple operation.  That is simple as long as setf! is
"static", but it is not simple for the new setf!.

To summarize: I think Guile should be standard Scheme + procedure
libraries + module system + some necessary support mechanisms (and,
maybe in the future, builtin object system).  I think we should be
restrictive in encouraging use of new language mechanisms, for the
goal of a small cognitive footprint, for portability, and for support
of efficient compilation (where I'm most interested in the last item).

/mdj