Brent Pinkney presented an example of what he wanted to do.
Not knowing his level of Smalltalk expertise, I took his
example at face value and showed how easy it is to do
exactly what he _said_ he wanted to do without new machinery.

Apparently this is not what he wants at all.

	Again, my question was how to get the arguments into an array.
	...
	Ah yes, it is fore-head smackingly easy to convert the arguments
	of the CURRENT method into an Array, however, pray tell how you
	would get the arguments for any method in your calling chain ?
	
At no time before this was it clear to me that he wanted to do this
for anything other than the arguments of the current method.

Nor does the example of Duration class>>days:hours:minutes:seconds:
clarify his intent; because you can implement exactly what the ANSI
specification says about _that_ without bringing arrays into it at all.

What's needed here is a better example.

The idea of reaching down the calling chain and picking up the
arguments of an ancestor arouses strong feelings of disgust in me.
(This is not a value judgement or anything like that.  I'm simply
reporting a fact about myself.  This disgust may be clouding my
judgement.)

It's a useful thing for a self-hosting debugger to be able to do.
After all, it is precisely the job of a debugger to ignore encapsulation
and reveal what's going on everywhere.

So I _wouldn't_ "get the arguments for any method in [my] calling
chain"; I would regard that as a "code smell" of twenty skunk intensity
and look for a refactoring.

What we need is an example where
    o1.m1 calls o2.m2 calls .... calls on.mn
and on.mn has a good reason to pick up o1.m1's arguments as an array
*without* o1.m1 expecting this to happen (otherwise it could build
the array itself and put it somewhere that on.mn could find it).