setter parameter order 
Author Message
 setter parameter order

This probably will seem boring with all the high level discussions going on
as of late, but it is of interest to me. I recently have been re-learning
the misfix syntax while playing with Gwydion Dylan. I realized that the
parameter order for the setter functions was changed from binding value to
value binding during the change from prefix to misfix. I was wondering why
this happened, where it was documented and if there was a good rationale
for it.

In the original Dylan the elegant Scheme-like
     (set! (horizontal my-point) 10)
could be written as the setter function call.
     ((setter horizontal) my-point 10)

After Design Note #20 New Syntax for Setter Variables (Change) Version 1,
March 1993 we go to the horizontal-setter syntax rather than the (setter
horizontal) call. This note gives the new function name syntax and refers
to Dylan (1992) book page 26 which is where the above definitions came
from. It follows that the syntax would be written as:
     (horizontal-setter my-point 10) ; binding, value
But both Apple Dylan and MacMarlais require:
     (horizontal-setter 10 my-point) ; value, binding

Which I suppose led to the current misfix call of:
     horizontal-setter (10, my-point); // value, binding

It doesn't seem to follow the prefix or functional language spirit,
although I know that was a conscience design decision. However, let and the
assignment operator carry the binding then value order, so I was wondering
how this current setter function call list order came about. It just seems
counterintuitive to me. I'm sure those who have always used the infix
language or come from a C background probably haven't noticed, where prefix
Dylan or Scheme coders should have. Maybe Andrew or Kim could field this
question best.


Los Angeles, CA   illustration & design |      {*filter*}dog mail system"
    http://www.*-*-*.com/ ~athene    | eti kai nun Hellada phileo



Sun, 03 Jun 2001 03:00:00 GMT  
 setter parameter order

Quote:

>Which I suppose led to the current misfix call of:
>     horizontal-setter (10, my-point); // value, binding

>It doesn't seem to follow the prefix or functional language spirit,
>although I know that was a conscience design decision. However, let and the
>assignment operator carry the binding then value order, so I was wondering
>how this current setter function call list order came about. It just seems

Actually, I noticed that as being somewhat strange too, and I'm known
as an advocate of infix syntax. It's probably too late to do anything
about it, but I'm curious as to what the reasons are as well.

Andreas

--
"Java requires the programmer to declare types and exceptions, simply to
make the compiler's job easy.  Which just seems like the wrong approach
to me:  CPU-cycles we have plenty of, good programmer cycles we don't."



Sun, 03 Jun 2001 03:00:00 GMT  
 setter parameter order

Quote:
> This probably will seem boring with all the high level discussions going on
> as of late, but it is of interest to me. I recently have been re-learning
> the misfix syntax while playing with Gwydion Dylan. I realized that the
> parameter order for the setter functions was changed from binding value to
> value binding during the change from prefix to misfix. I was wondering why
> this happened, where it was documented and if there was a good rationale
> for it.

A setter takes a place and a new value.  You point out that the intuitive
argument order would be

  foo-setter (place, new-value)

I agree that would be preferable, if it worked.  Unfortunately, it
fails in those cases where the 'place' is described by a variable
number of arguments.  The primary example of this is aref-setter,
which takes a rest argument of indices.  If the new-value came at the
end (after the array and the indices) you wouldn't be able to
specialize on it.  Similar problems come up with getters/setters
that accept keyword arguments.

The only ways around this are to make the setter always come first,
or always come second.  Having it come second would sometimes put
it in the middle of the 'place', which seemed even less desirable
than having it come first.

Unfortunate, but it makes sense given the constraints.



Sun, 03 Jun 2001 03:00:00 GMT  
 setter parameter order


Quote:

> > This probably will seem boring with all the high level discussions going on
> > as of late, but it is of interest to me. I recently have been re-learning
> > the misfix syntax while playing with Gwydion Dylan. I realized that the
> > parameter order for the setter functions was changed from binding value to
> > value binding during the change from prefix to misfix. I was wondering why
> > this happened, where it was documented and if there was a good rationale
> > for it.

> A setter takes a place and a new value.  You point out that the intuitive
> argument order would be

>   foo-setter (place, new-value)

> I agree that would be preferable, if it worked.  Unfortunately, it
> fails in those cases where the 'place' is described by a variable
> number of arguments.  The primary example of this is aref-setter,
> which takes a rest argument of indices.  If the new-value came at the
> end (after the array and the indices) you wouldn't be able to
> specialize on it.  Similar problems come up with getters/setters
> that accept keyword arguments.

> The only ways around this are to make the setter always come first,
> or always come second.  Having it come second would sometimes put
> it in the middle of the 'place', which seemed even less desirable
> than having it come first.

> Unfortunate, but it makes sense given the constraints.

Also, I'm not sure of the background of the folks with the prefix preference,
but the current Dylan order is consistent with SETF functions in Common Lisp.

__Jason



Tue, 05 Jun 2001 03:00:00 GMT  
 setter parameter order


Quote:

>Also, I'm not sure of the background of the folks with the prefix preference,
>but the current Dylan order is consistent with SETF functions in Common Lisp.

That was a case a convergent evolution more than direct lineage.  Common Lisp
SETF has to deal with the same issues of variable number arguments describing
the place.


Tue, 05 Jun 2001 03:00:00 GMT  
 setter parameter order

Quote:

>which takes a rest argument of indices.  If the new-value came at the
>end (after the array and the indices) you wouldn't be able to
>specialize on it.  Similar problems come up with getters/setters

That's actually a good reason, and I must admit that the idea of
specializing on setters didn't occur to me before. It sounds useful.

Andreas

--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
                -- Tom Cargil, C++ Journal.



Tue, 05 Jun 2001 03:00:00 GMT  
 setter parameter order


Quote:

>>which takes a rest argument of indices.  If the new-value came at the
>>end (after the array and the indices) you wouldn't be able to
>>specialize on it.  Similar problems come up with getters/setters

>That's actually a good reason, and I must admit that the idea of
>specializing on setters didn't occur to me before. It sounds useful.

Specialized slots specialize on setters.


Fri, 08 Jun 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Argument order in setter functions

2. Parameter order for []= methods

3. Fixed parameter evaluation order

4. Efficiency and Parameter Ordering in COSMO

5. Parameter evaluation order

6. Attribute order in attlist parameter of TCLXml

7. general order of parameters

8. Order of ORDER output

9. ORDER is not in order

10. ANS Standard - Search order words : SET-ORDER Query

11. from high order to first order

12. Fortran source code for 8th order RKS and RKV with 9th order error control

 

 
Powered by phpBB® Forum Software