Discussion:
[Larceny-users] procedure introspection
Jose A. Ortega Ruiz
2009-03-13 00:51:29 UTC
Permalink
hi,

i have a new scheme-emacs interaction mode in the works that provides,
for scheme, functionality akin to slime's for CL. it's more or less
generic, in the sense that i can make it work with any scheme providing
the right amount of introspection. despite all the bad press it
receives, so far only guile is giving me a decent introspection API (PLT
has it too, but i have other quibbles with it). i was wondering how
larceny fares in this regard; in particular, if the interface for
'operations on procedures' described in

<http://larceny.ccs.neu.edu/doc/user-manual.html#id2542921>

were functional, i'd have much of what i need. alas, those procedures
seem to be not (yet?) implemented. so my question: are there plans to
provide them in a future version of larceny? is it just a 'simple matter
of programming' what's needed or, on the contrary, major changes in
larceny's inner workings are needed to make them real?

thanks a lot for your time,
jao
--
A student came to the master and asked, for the master was one of them
who knew such things: "Does Emacs have the Buddha nature?" The master
contemplated this for some time, and answered: "I don't see why not,
it has about everything else."
William D Clinger
2009-03-13 14:33:39 UTC
Permalink
Post by Jose A. Ortega Ruiz
in particular, if the interface for
'operations on procedures' described in
<http://larceny.ccs.neu.edu/doc/user-manual.html#id2542921>
were functional, i'd have much of what i need. alas, those procedures
seem to be not (yet?) implemented.
Those operations are implemented, but the first five
(make-procedure, procedure-length, procedure-ref,
procedure-set!, and procedure-copy) are deprecated
because they are useful only to compiler writers and
system implementors.

The operations beginning with procedure-arity are
implemented minimally; the only ones that are likely
to return useful information (as opposed to #f) are
procedure-arity and procedure-name, and even the
procedure-name procedure returns #f more often than
you'd like.

The procedure-expression procedure will work if you
incant (include-source-code #t) to change that
compiler switch, but it exposes some confusing
renaming of keywords, and that compiler switch is
automatically turned off when compiling files (to
keep the compiled files from becoming much larger).
Post by Jose A. Ortega Ruiz
so my question: are there plans to
provide them in a future version of larceny? is it just a 'simple matter
of programming' what's needed or, on the contrary, major changes in
larceny's inner workings are needed to make them real?
It is indeed a simple matter of programming. The
current development system is already capable of
recording source code positions, and the compiled
code and the compiler's intermediate representations
already contain documentation slots where that info
should go.

I'll try to get this into the next release (v0.97),
but if not it should certainly be improved in v0.98.

Will
Jose A. Ortega Ruiz
2009-03-13 19:20:35 UTC
Permalink
William D Clinger <***@ccs.neu.edu> writes:


[...]
Post by William D Clinger
The operations beginning with procedure-arity are
implemented minimally; the only ones that are likely
to return useful information (as opposed to #f) are
procedure-arity and procedure-name, and even the
procedure-name procedure returns #f more often than
you'd like.
I've observed that much. The latter is probably not a problem for my
system.
Post by William D Clinger
The procedure-expression procedure will work if you
incant (include-source-code #t) to change that
compiler switch, but it exposes some confusing
renaming of keywords, and that compiler switch is
automatically turned off when compiling files (to
keep the compiled files from becoming much larger).
Unless procedure-arity is extended to provide them, i'd be using
procedure-expression to get the arguments' *names*, to display short
help notices in emacs echo area (using eldoc). I guess i can always
recompile things dynamically in the REPL with (include-source-code #t)
to get the procedure's expression, although it's a bit of a waste
because i only need the lambda formals.

Is there a similar facility for macros?

[...]
Post by William D Clinger
It is indeed a simple matter of programming. The
current development system is already capable of
recording source code positions, and the compiled
code and the compiler's intermediate representations
already contain documentation slots where that info
should go.
That's very good news!
Post by William D Clinger
I'll try to get this into the next release (v0.97),
but if not it should certainly be improved in v0.98.
Excellent. Very much appreciated.

While we're at it, i've got a couple more questions:

- is there (or could there be in future versions) a way to obtain a list
of callers and callees of a given procedure?
- when hacking in other schemes with a module system (e.g. guile or
s48), one has the ability of evaluating forms in a module's context
when in the REPL. R6RS precludes REPLs, so the question is moot there,
but what about larceny's REPL in ERR5RS mode?

Thanks a lot for your prompt answer and support. I'm hoping to be able
to provide a pleasant little emacs environment for larceny hacking!

Cheers,
jao
Jose A. Ortega Ruiz
2009-03-13 21:35:32 UTC
Permalink
Hi again,

Sorry, i forgot a question in my previous response: is there a way to
get the list of bound identifiers in a given environment/library? (i'd
use that to provide symbol completion in Scheme buffers).

Thanks,
jao
Felix Klock
2009-03-14 00:27:43 UTC
Permalink
jao-
Post by Jose A. Ortega Ruiz
Sorry, i forgot a question in my previous response: is there a way to
get the list of bound identifiers in a given environment/library? (i'd
use that to provide symbol completion in Scheme buffers).
You can query for the environments provided by an environment object,
such as the interaction environment. (This is not the same thing as
the lexical environment of a particular expression.)

The relevant procedure is environment-variables -- this functionality
is the basis of the apropos library, which I've included a
demonstration of below.

-Felix

Larceny v0.97a3 (alpha test) (Mar 4 2009 11:51:41, precise:Posix
Unix:unified)
/home/pnkfelix/.larceny: adding lib/Experimental to require path
larceny.heap, built on Wed Mar 4 12:44:23 EST 2009
Post by Jose A. Ortega Ruiz
(require 'apropos)
#t
Post by Jose A. Ortega Ruiz
(apropos 'macro)
(environment-get-macro
environment-macro?
environment-macros
environment-set-macro!
macro-expand
macro-expand-expression
macro-expander)
Jose A. Ortega Ruiz
2009-03-14 01:35:23 UTC
Permalink
Post by Felix Klock
jao-
Post by Jose A. Ortega Ruiz
Sorry, i forgot a question in my previous response: is there a way to
get the list of bound identifiers in a given environment/library? (i'd
use that to provide symbol completion in Scheme buffers).
You can query for the environments provided by an environment object,
such as the interaction environment. (This is not the same thing as
the lexical environment of a particular expression.)
Excellent. This is exactly what i was asking for. Looks like i can
already start integrating larceny in my emacs thing. Thanks, Felix.

Cheers,
jao
William D Clinger
2009-03-15 19:35:19 UTC
Permalink
Post by Jose A. Ortega Ruiz
Unless procedure-arity is extended to provide them, i'd be using
procedure-expression to get the arguments' *names*, to display short
help notices in emacs echo area (using eldoc).
Larceny already retains the variable names, but we never
extended src/Lib/Common/procinfo.sch to provide access to
them. How about we add procedure-arguments to fix that?
Post by Jose A. Ortega Ruiz
Is there a similar facility for macros?
No.
Post by Jose A. Ortega Ruiz
- is there (or could there be in future versions) a way to obtain a list
of callers and callees of a given procedure?
Not really.

In higher order languages like Scheme, the general problem
is undecidable, so you'd have to settle for an approximation.

Larceny's compiler computes a first-order approximation that's
limited to the compilation unit, but I doubt whether that
would be good enough for your purposes.

Will
Jose A. Ortega Ruiz
2009-03-15 20:24:32 UTC
Permalink
Post by William D Clinger
Larceny already retains the variable names, but we never
extended src/Lib/Common/procinfo.sch to provide access to
them. How about we add procedure-arguments to fix that?
That'd be nice indeed.
Post by William D Clinger
Post by Jose A. Ortega Ruiz
- is there (or could there be in future versions) a way to obtain a list
of callers and callees of a given procedure?
Not really.
In higher order languages like Scheme, the general problem
is undecidable, so you'd have to settle for an approximation.
Larceny's compiler computes a first-order approximation that's
limited to the compilation unit, but I doubt whether that
would be good enough for your purposes.
No, probably not. I guess i'll have to live without that feature.

Thanks!
jao

Continue reading on narkive:
Loading...