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

Re: straw proposal: heuristic info from procedures



|   Date: Mon, 6 May 1996 15:03:22 -0500 (CDT)
|   From: Shriram Krishnamurthi <shriram@cs.rice.edu>
|   References: <318E0D40.1375@ccs.neu.edu>
|   Reply-To: shriram@cs.rice.edu
|
|   In MzScheme, the arity procedure (whose documentation is available at
|   http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node43.html#SECTION003200000000000000000
|   or http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/mzscheme.html
|   followed by the "Arity" entry) returns
|
|   1. a number,
|   2. the structure arity-at-least, whose field value gives the actual
|      minimum number, or
|   3. a list of elements of type 1. and 2. (representing case-lambda).

That sounds reasonable.

|
|   > (procedure-source-file _proc_)
|   > 
|   >   Returns the name of the file that contains the source code for
|   >   _proc_, as a string, or returns #F if this information is not
|   >   available.
|   > 
|   > (procedure-source-position _proc_)
|   > 
|   >   Returns an exact integer that specifies the number of characters
|   >   that precede the opening parenthesis of the source code for _proc_
|   >   within the source file returned by PROCEDURE-SOURCE-FILE, or
|   >   returns #F if this information is not available.
|   > 
|   > (procedure-code _proc_)
|   > 
|   >   Returns the source code for _proc_ as a lambda expression, in the
|   >   traditional representation as a list, or returns #F if no source
|   >   code is available for _proc_.
|
|   These three could be merged if instead there were a single procedure
|   that returned the location-annotated source of the procedure.  At
|   least, these three could be defined as primitives on top of that.
|
|   Also, I really don't like this dependence on "files", but so be it.

I would like to distinguish between the source position and the
s-expression for the procedure.

The source position can vary a lot according to
- it came from a file (e.g. load)
- it came from an unnamed emacs-like buffer
- it came from an interactive stream
- it is the result of macro-expansion of define-record, or whatever
- it is the result of dynamic code generation by the program itself

Thus making it file-specific is too restrictive.

The s-expression, however, is somewhat independent of where the
characters came from, although it may be hard to produce because of
macro expansion.