[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Argument lists: a proposal to shoot at
- To: NGALL@G.BBN.COM
- Subject: Re: Argument lists: a proposal to shoot at
- From: mike@a
- Date: Fri, 27 Jun 86 10:36 EST
- Cc: gls@ZARATHUSTRA.THINK.COM, common-lisp@SU-AI.ARPA
- Reply-to: firstname.lastname@example.org
Date: 26 Jun 1986 19:17-EDT
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
Sorry, but inferring anything about 'probably stack based' at run time
just turns my stomach. Why not ask how many are 'register based'?
Why not just call (disassemble ...)????
There are three kinds of things going on here. One is to somehow figure
out how to call a function so you can avoid a run time error, etc.
This is best served I think by enhancing (type-of ...) for funcallable
objects. The second is for programming environments, which is best
served by keeping argument lists around on a property list, or something,
since the idea is to inform a programmer how the call works, and to
give him some idea of the semantics of the arguments by allowing access
to the actual argument names.
The third, and most troublesome is so that programs can reason about
how arguments are passed, i.e., can do things like 'probably register
based', and so on. Why is this needed?
I think we should provide (arglist ...) which returns the literal
arglist of functions, to address user interface considerations.
We shouldn't break the function abstraction any more than that.
Gold Hill Computers