Re: setter problem

[Chris Dollin <kers@hplb.hpl.hp.com>]

Harry Bretthauer (|) replies to me (| >):

| > Why not do it the way T and Pop do, and make setter be a function?
| >
| > (The only argument I've heard against this is that you'd like to be able to
| > export the accessor and not the setter of a function, which is easy if they're
| > symbols. But it seems to me that (a) you can get that effect by introducing an
| > auxilliary function, and (b) if it's that common, you can introduce export
| > syntax to have the system do it for you. Compared to the simplicty and
| > elegance of procedures-with-setters, this seems a feeble case. IMAO.)
|
| There are some more aspects, where, I think the setter should have
| similar behavior as the reader. For example:
| 1. if the reader binding is constant, the setter "binding or table
|    entry" should also.
| 2. if a reader reference can be analyzed statically (detecting errors,
| etc.), the setter reference should also.

These can be done if there is a way to assert that (setter x) is an invariant
for some particular x. Since this is a useful thing to be able to assert for
*any* function-value combination (eg, (sin x), (car x)), there seems to be no
compelling reason to have special forms for setter rather than making it a
procedure.

| This can be better achieved and explained by special forms, one for
| defining setters and one for refering them, rather than by a function.

I don't agree (except I'd expect a special form or macro for *defining* them,
for the sake of common use).

| This could be generalized to structure the lexical module bindings
| with respect to some criteria which are orthogonal to the module
| structure. It might be also usefull to allow language extenders to define new
| binding spaces with lexical or other semantics.

But if we do that (for example, by attaching suitable predicates to bindings)
then we can attach eg information about the immutability of the setter slot of
procedures, once again dispensing with the need for an extra name space in
favour of the setter-as-function solution.

I've *used* setters-as-functions. Not being able to pass a function as a
parameter and get at its setter would be a *pain* -- I'd no more want to do
without them than I'd want to do without lexical binding, partial
application, or properties (hash tables). I think the getter-and-setter
procedures are a natural pair; associating them only by name is surely an
easily-fixable mistake.

Kers.       | "A foolish hobgoblin has the consistency of little minds".