Re: SRFI-17

[Keith Wright <kwright at gis dot net>]

> From: Per Bothner <per@bothner.com>
> 
> Keith Wright <kwright@gis.net> writes:
> 
> >       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".

But it is not just willful pig-headedness!  The term "lvalue" was made
out of "L" for location and "value", and has, for the past two or
three decades, been used pretty consistently to refer to locations
that are values.  This has led to about two-thirds of the subsequent
discussion of SRFI-17 being ranting about a proposal you never made.
If there is any willful perversity here it seems to me to lie in using
the term "L-value" and expecting everyone to understand that, contrary
to tradition and etymology, it is not intended to signify a value.

I say it has "nothing to do with the case" because, as I read the SRFI,
the term "lvalue" is used only when discussing features of APL, Common
LISP, and Algol 68.  It is never defined as a technical term when
describing the proposal itself.  At best it is a motivating argument
for the proposal, but the masses do not seem to be motivated by it.

> >   (2) Tighten up the spec.
> 
> One has been posted;  I have asked the editors to merge it in.

I know, I saw it, but the merge seems not to have happened.
I don't understand the procedure for making changes, but it seems
to be broken.  Maybe SRFI-17 needs to be withdrawn and a re-written
version submitted under a new number.

> >   (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.

I'm not sure it is the main disagreement, but it may be the one
least likely to go away with further discussion.  At the risk of
being tedious, I repeat the point I made a year or so ago:
The proposal may be an unambiguous extension, but it is not the
only possible unambigous extension.  (One alternative is to really
treat locations as values.)  Some people object to an attempt to
hijack the already-defined name, but would accept it as an experimental
extension with its own name.

I don't see any technical reason not to give it a new name.  If the
political motive is to try to gain acceptance by using the choicest
name, it seems to be backfiring.

> > (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.

Do you mean (SETF! F VALUE), to mean the same as (SET! F VALUE)?
If so, then I don't see why it's a major flaw, since it is so easy
to add.  By adding it you make some people like it better, and
other people like it less.  Whether it is a net win in popularity,
I do not know.  I do know that I don't care to debate it.
De gustibus non disputandum.
(But if someone had something genuinely new to say about it I would
be glad to learn what it is.)

If you meant (SETF! (F) VALUE) as you wrote it, then I am confused.
I didn't know the original SRFI allowed it, and I am not sure what
it means.  It seems to be an invocation of a setter procedure,
giving it a new value, but no place to put the value.  At best
a harmless but useless degenerate case.

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

But that is true in any case.  It is only with setters that have "extra"
arguments, such as VECTOR-SET! that it makes any difference.
I don't see why you would care what the setter for a built-in procedure
would be, since the whole point of the proposal is to dig that up
automatically.  The order I chose seems definitely better from
the point of view of defining a new setter.

For example, suppose you implement multi-dimensional arrays as vectors
of vectors...  to any depth, and access them by

(define (array-ref a . subs)
  (if (zero? (length subs))
      a
      (apply array-ref (vector-ref a (car subs)) (cdr subs))))

then the corresponding setter procedure is

(define (array-set! a val . subs)
  (if (= 1 (length subs))
      (vector-set! a (car subs) val)  ; or (setf! (vector-ref (car subs)) val)
      (apply array-set! (vector-ref a (car subs)) val (cdr subs))))

It would be a major pain in the butt to write this recursion with the
arguments in the other order.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---