[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: associative methods

    In Dylan there are a number of method's that take an unlimited number
    of arguments and convert to `binary' methods (e.g., = translates to
    binary=).  Unfortunately, there is no way for a user to define their
    own and I'm positive that users are going to want their own.  Sure,
    one can simulate this conversion, but it is inefficient (i.e., conses
    #rest list on heap and is performed at run-time).
    One way to make this facility available to users would be to introduce
    a new construct such as `define-associative-method' for this facility...

In my opinion, your proposed solution is too specialized and doesn't get to
the heart of the problem.  The real problem is that the #rest machinery is
inherently expensive to use, since it is defined as creating a sequence at
runtime.  The proverbial SSC ("sufficiently smart compiler") could prove in
many cases that the sequence is confined within the method's dynamic extent
and can therefore be stack-allocated, but I think that users will become
confused and anxious about which cases heap-allocate and which don't.

For cases like + and =, in which an unlimited number of arguments are
consumed locally, I like the idea of providing some mechanism like the old
Maclisp LEXPRs.  For example, the arglist might contain "#MORE N", which
would bind n to the number of arguments that were passed.  Then the method
can iterate, using some form like (MORE-ARG i) to access each argument i.
In this case, there would be no runtime consing.  #MORE might replace
#REST (with the addition of an ARGS-TO-LIST function), or the two could
coexist as alternative arg-list forms.

Sometime in the near future I plan to write up a detailed proposal on
more-args for people to consider, but I still have to work out some

-- Scott
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu