John Cowan <xxxxxx@mercury.ccil.org> writes:

> I don't like using set!, because (set! x y z) depends on the current
> value of x, whereas (set! x y) ignores the current value.  Using set
> (with no !) might be better.

I don't think dropping the ! is a good idea, since it dispatches to a
variety of *-set! procedures and is clearly mutative.

While there's kind of a conceptual inconsistency between the two- and
three-argument uses of set!, I think this is unlikely to lead to
confusion in practice.

Input from more people welcome.  Also see last part of this mail though.

> The opaque records of R6RS and SRFI 99 extensions should be explicitly
> excluded from this SRFI.

The SRFI doesn't really use any form of inspection into record types.
It just piggybacks `define-record-type' to take note of the newly
defined data type, and create tables mapping symbols to the data type's
accessors and modifiers.  So I think it's fine to support them.

Or am I missing something?

> If SRFI-4 homogeneous vectors are supported by the implementation,
> this SRFI should require that they be supported here too.

Indeed.  I'll specify that, and add support for it in the reference
implementation.

> It would be easy to allow default arguments for all types of refs,
> and I think that should be done, for convenience and uniformity.

I would rather reserve that feature for types which may have fields that
"exist" but hold no value.  (In this sense, hashtables have infinitely
many fields; you get the idea.)  It's natural for those types, whereas
using (ref #(0 1 2) 3 'default) as a shorthand for a bounds-check and
fallback value is a rather obscure abbreviation, and for record types
it's even more strange.  Those are more likely to be programmer errors
than anything else, I imagine.

More views welcome.

> Supporting a SRFI-17 setter for ref makes sense, but I think
> (set! (car foo) bar quux) is even more confusing than (set! foo bar
> quux).

While I don't find (set! foo bar quux) particularly confusing, I have to
admit (set! (car foo) bar quux) is a worrying one.  Although, I'm not
sure whether it would lead to actual problems.  It's unlikely that one
would write a bug due to the confusion, and someone reading the code
should suffer from a mild irritation at most, which in turn can be
salvaged by let-binding (car foo) first to make the code clearer.
(There are many ways to write irritating code!)

For now, I don't see it as a show-stopper to support 3-argument set!,
however with Mark Weaver's input on IRC I began pondering on making the
whole design closer to (or at least incorporating the one of) Gauche's
ref* AKA ~ operator.  That, plus I just realized I could support pairs
distinctly from lists by testing the field argument with `procedure?'
(meaning it can't be a list index, and is likely to be car/cdr), so your
example would more idiomatically become

(set! (~ foo car bar) quux),

where (set! structure key value) is still kept for the simplest cases,
because in my opinion it's nicer than (set! (~ structure key) value).
Having to type the extra parentheses and tilde for the arguably most
common use case is, in my opinion, a no-no, and I see no harm in
continuing to support the 3-argument variant.

I could be fooling myself because I'm demotivated to trash too much of
the initial design though, which I came to like.

What do others think?

Should it be fine to support (set! obj key val) as a special-case as a
synonym to (set! (~ obj key) val), once the latter is supported for
arbitrary key-chains?  Or is it likely to do more harm than good?

Thanks for all the input so far!

Taylan