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] |
Mikael Djurfeldt <mdj@nada.kth.se> writes: > Maciej Stachowiak <mstachow@MIT.EDU> writes: > > > I think a purely dynamic one would be more in the spirit of Scheme. > > I tend to agree. But adding anything at all is against the spirit of Scheme! Now all we need is the mythic SSC that's able to predict the future to make the 'Schemely' version efficient. > In STk, (setter car) is treated as a variable name in some places. > But since, you can't do things like > > (let (((setter car) set-car!)) ...) > > and since the syntax > > (define (setter x) ...) > > becomes very ambiguous, the idea is a bit unschemey. Why is it good enough for STk? As the Japanese TQM gurus say, ask why seven times. Somehow, they make do with this un-Schemeliness. Is any tradeoff against 'Schemeliness' ever acceptable, or does this trump all arguments? Perhaps we could bundle up R5RS into a little red book, and whack people over the head with it. > But, what I can't accept with the dynamic setf! is that it would be > difficult to compile to efficient code. Yes. > Now I'm thinking of letting #:accessor <name> create the accessors > <name> and set-<name>! instead. You are caught in a maze of twistly little accessors and setters, almost all alike (but not quite). And now you much go to bed with no incf or rotatef, too. To extend you argument, isn't define-class un-Schemely? Perhaps it should be removed because it's an obviously user-definable add-on. And besides that it's a macro, so what happens if someone redefines define-class at runtime? It's OK to admit that some things should be done at compile time, and not messed with after that point. Accept this and move on. setf is one of these things. You see this 'Schemely' argument has no legs after a point. It's all about providing useful and well designed features to the programmer. If an extension goes in a different direction than the standard started out, that doesn't make it an a priori 'bad thing (tm)'. Sorry for the pedantry, I'm a bit cross tonight. I just thought I'd give you the right-wing CL view for some balance. -russ