Shriram Krishnamurthi <xxxxxx@cs.rice.edu> writes:

> I personally am disappointed that the proponents of this SRFI have
> done little other than indicate it is good because it exists, while it
> exists because it is good.

That is a falsehood.

> Matthias and others have repeatedly raised
> objections to it, on the grounds that it conflates two distinct
> notions, and these haven't ever been properly answered.

I am sorry, but we not in your classroom, and you don't get to
define what a "proper answer" is.  I have argued in a number of
responses that the notions are highly related, and that it is
plausible to view variables as settable components of an
environment.  I will not repeat my answers here.

You may have your reasons to think conflating the two notions is a
mistake; others think it makes sense, including some of whom have
thought about programming language design issues for decades, and
designers of many other programming languages, including at least one
recent Scheme-inspired language (Dylan).  It is the height of academic
arrogance to dismiss such experience because it is not compatible with
your favorite theory.  (Experience teaching beginning students can
also provide useful insights, but little more.)

> (A response like "I don't like the idea of multiplying syntax
> gratuitiously" is hardly an answer, because the problem here is not
> syntactic but semantic.)

We want to conflate the syntax *because* we view the semantic
notions as related.  That is why I don't want to use setf instead
of set!, as some people have proposed.  (I have nothing against
people preferring to use setf instead set! - but that is not my
preference, and this is my proposal.  Those who prefer setf should
make an alternative proposal - and I'd be happy to co-ordinate
things so the proposals are compatible.  However, I would rather
withdraw my proposal than change this part of it.)

There seem to be two main classes of objections:
(1) overloading the assignment operator (`set!' in Scheme, `:='
in Dylan, etc) is a bad/dangerous idea in principle;
(2) overloading the assignment operator is a bad idea *in Scheme*
or any established language because it might cause confusion
for existing users or tools.

I have somewhat more sympathy for (2).  However, I don't think it's a
very strong objection, as it seems very hypothetical, and because
Scheme is not currently a single language with an established
standard, but a whole class of related partially-compatible existing
dialects, rather than a single language.

> I had hoped for a better discussion on a SRFI.  But there's nothing
> I or anyone else can do about it, and the SRFI process allows
> strategies such this to succeed in producing final SRFIs.

Now he accuses me of abusing the process!  But the whole *point*
of the srfi process, as advertised, was to allow us to make
progress on standardizing aspects of Scheme on which there *isn't*
consensus.  The rNrs process bogged down because it required
consensus, which proved impossible to get.  So if some srfis
get approved that you dislike, well that just proves the
system works.  It's not a problem, it's a feature.

> I hope it won't be repeated, but those hopes do nothing to
> address the status of SRFI-17.  Perhaps it's just best to close this
> out without further ado.

I would just as soon drop the whole mess, but there are others
who definintely want this feature, so it seems like it makes
sense to standardize the specifics.
--
	--Per Bothner
xxxxxx@bothner.com   http://www.bothner.com/~per/