This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 are here. Eventually, the entire history will be moved there, including any new messages.
Shriram Krishnamurthi <shriram@xxxxxxxxxxx> 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 per@xxxxxxxxxxx http://www.bothner.com/~per/