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

*To*: will@ccs.neu.edu*Subject*: Re: Revised straw proposal for heuristic info*From*: "R. Kent Dybvig" <dyb@cs.indiana.edu>*Date*: Mon, 13 May 1996 10:22:08 -0500 (EST)*Cc*: rrrs-authors@martigny.ai.mit.edu

> (procedure-arity _proc_) > Returns information about the arity of _proc_. If the result > is #F, then no information is available. If the result > is an exact non-negative integer k, then _proc_ requires > exactly k arguments. If the result is an inexact non-negative > integer n, then _proc_ requires n or more arguments. If the > result is a pair, then it is a list of exact non-negative > integers, each of which is a number of arguments that will be > accepted by _proc_; the list is not necessarily exhaustive. Why limit the list in the third case to exact non-negative integers? By doing so, procedure-arity can't precisely describe procedures that accept, for example, 1 or 2+ arguments. I prefer encoding "n or more arguments" as (- -1 n), e.g., 0 or more is -1, 1 or more is -2, etc., since this encoding does not presume support for both exact and inexact numbers. Also, I think that using inexact numbers for this purpose is misleading even if it is cute. > (procedure-source-position _proc_) > Returns information about the position of the source code for > _proc_ within the source file specified by PROCEDURE-SOURCE-FILE. > If the result is #F, then no information is available. If the > result is an exact integer k, then k characters precede the > opening parenthesis of the source code for _proc_ within that > source file. Procedure expression do not necessarily begin with an open parenthesis in all implementations. I suggest simply eliminating "the opening parenthesis of". > (procedure-expression _proc_) > Returns information about the source code for _proc_. If the > result is #F, then no information is available. If the result > is a pair, then it is a lambda expression in the traditional > representation as a list. Source-level procedure expressions are not necessarily represented as lists in all implementations. (They may be after expansion.) I suggest replacing "as a list" with "as a datum". Also, the text should specify whether the expression is source-level or post-expansion, or it should explicitly leave this unspecified. Kent

**Follow-Ups**:**Re: Revised straw proposal for heuristic info***From:*William D Clinger <will@ccs.neu.edu>

- Prev by Date:
**Re: Why would anyone want opacity?** - Next by Date:
**Why would anyone want opacity?** - Prev by thread:
**bye.** - Next by thread:
**Re: Revised straw proposal for heuristic info** - Index(es):