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