Re: SRFI-17

[Per Bothner <per at bothner dot com>]

Keith Wright <kwright@gis.net> writes:

> The most important of the good points are:
>   (1) Delete bogus ideas that are not part of the proposal.

Thanks for not taking part in the raving.

>       In particular delete all that talk of lvalues, it has nothing
>       to do with the case, and misleads people into thinking you
>       are proposing "first class variables".

It does have a lot to do with the case - but the term misleads people
because they have the wrong-headed idea that "lvalues" are "values".

>       Also delete the
>       "questionable definitions" like (set! (string->symbol x) v).

I agree.

>   (2) Tighten up the spec.  It doesn't make it to answer a
>       Scheme Request For Implementation with
>         "It is not possible to give a really portable
>          implementation, but it should be straight-forwarded
>          to modify an implementation as needed", especially
>       when an implementation is so easy (modulo efficiency).

One has been posted;  I have asked the editors to merge it in.

>   (3) Change the name.  A lot of people who wouldn't mind an
>       extension are put off by muddling up standard syntax.

Well, that of course is the main disagreement:  whether to
call it setf! or stick to set!.  The latter is not "muddling up
standard syntax";  it is an unambiguous extension.

> (define-syntax setf!
>    (syntax-rules()
>      ( (setf! (f obj arg ...) value)
>        ((setter f) obj value arg ...))))

I notice you don't allow:

        (setf! (f) value)

I think that is a major flaw in your proposal.

> We define:
>   (setf! (proc arg ...) value)
>     as  ((setter proc) value arg ...)
>     rather than ((setter proc) arg ... value)
> because it works better with procedures that take a variable number of
> arguments.  This means that the setter for the function vector-ref is
> not really set-vector!, but a similar procedure with the arguments
> permuted.

I think most people preferred (setter car) == set-car! but it's hard to
tell.  (That wasn't the really contenious part - though I had expected
more discussion on it.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/