Re: setter problem

[thant@void.esd.sgi.com]

Okay, so (setter m) is actually a variable in and of itself.  But that
doesn't make sense with (set! (m foo) item).  Is there similar macro
magic going on here? Is this syntax also under redesign consideration?

According to Andrew LM Shalit, Dylan does things this way so that 
the getter and the setter can be exported (or not) separately.
I could also see that there might be performance hits in building
'setter' into a dispatcher.  

But all of a sudden, Dylan doesn't seem as elegant as I originally 
thought it was.  Isn't there a way of turning setter into a dispatcher
that at compile-time can be, but may not be optimized out of existence?
(-Since I assume some fancy optimizations happen with the general
method dispatcher anyway?)  Assuming this can be done, can't the
export information that can't be compiled out be assimilated into 
the dispatcher?

thant

P.S.  Although, I've never used T, I had heard of T's setter 
function and I did originally think that Dylan's was the same 
thing.