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


Russell McManus <mcmanus@IDT.NET> writes:

> But adding anything at all is against the spirit of Scheme!

Yes.  :)

No, seriously, I think the Scheme *language* is useful enough.  What
we need is libraries of procedures and macros which makes it easy to
write real-world applications.

> Now all we need is the mythic SSC that's able to predict the future
> to make the 'Schemely' version efficient.

Yeah, I'm very much against that people start using features in their
code which will make it hard to compile, and which will set up new
constraints for people implementing new versions of the Guile
evaluator.

> Perhaps we could bundle up R5RS into a little red book, and whack
> people over the head with it.

:)  If everyone read a paragraph out of R5RS every evening, I think
this would become a better world.

> 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)'.

I'm not against adding useful things when they are really needed.
E. g., we added fluids to Guile.  They are also a new language
mechanism.  But they are also really needed when you start working
with threads.

I don't see that kind of strong need of `setf!' to motivate a new
language mechanism.  I think `set!' is useful enough.

I would have accepted `setf!' if it could be written as "syntactic
sugar" so that it could be reduced to existing language mechanisms,
but Maciej showed that this leads to situations where the language
becomes nonintuitive.  And consistency and intuitive behaviour is
really really useful properties in a language.

I think Guile's fate would be much worse if we ended up with a small
version of Common LISP than if we're omitting some useful but
redundant language extensions.

Though, I appreciate your pushing for usefulness.  Please continue to
do so!

/mdj