[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: where is srfi-17 going?

This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.



Shriram Krishnamurthi <shriram@xxxxxxxxxxx> writes:

> Per Bothner wrote:
> 
> > One reason for using a single name is that I'm interested in
> > experimenting with alternative syntaxes, including use of infix
> > operators. [...]
> 
> I fail to see why a new operator, GENERALIZED-MUTATE (say), could not
> meet your needs just as well.  ... Why does the chosen name have to be SET!
> and nothing else?

It doesn't.  I was explaining where I was coming from, and one reason
I feel it is natural to have a conflated mutator, at least in languages
that use an infix syntax.  Most of the arguments against generalized-set!
seem to have been against the general idea of a conflated mutator,
even their use in languages that do use infix syntax.

> I just want to know why that one name, which already has a fixed
> syntax and semantics in standard Scheme.

Perhaps because I've been using Kawa as a framework to work out some
ideas on language design, in the context of a language that is
compatible with Scheme.  That approach may be fine for Kawa; perhaps
that is not appropriate for Scheme in general.  I do admit in some
ways Kawa is straying from "the spirit of Scheme": for example it has
optional type specifiers.  (Worse, use of types is quite ad hoc, at
this time.)

Still, there are at least two Scheme dialects that *do* implement
extended set!, so it seemed to make sense to make a srfi for it.

> After all, if your source language has := rather than SET!
> (which would likely be a poor choice of name in a traditional infix
> syntax, since `!' may well mean something else), then your translator
> can pick any old name it wishes in the target language.

Yes.  I wrote something similar, but edited it out.
-- 
	--Per Bothner
per@xxxxxxxxxxx   http://www.bothner.com/~per/