[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: associative methods
- To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
- Subject: Re: associative methods
- From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
- Date: Mon, 05 Oct 92 01:56:37 -0400
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Sun, 04 Oct 92 19:55:21 +0000. <199210041855.AA01084@miles.ircam.fr>
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 E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213