Fully introspectable Code objects?

2005-05-29 Thread Ingo Blechschmidt 
Hi,

while responding to nothingmuch++'s post function signatures?, I
thought that it'll be great if Code objects were fully introspectable.

I.e.:
  foo.statements; # List of statements
  foo.statements[0]   # First statement
  foo.statements[2] = ...;# Statement modification?

And all objects returned from the introspection methods should stringify
appropriately, so that...
  say ~sub { 42 + $^a };   # prints
  sub ($a) { return 42 + $a; }

Is this going too far?
Is this wanted?
Is it useful?

(At least readonly access would be nice, as allowing writes to
foo.statements will make compiler optimisations much
harder/impossible.)


--Ingo

-- 
Linux, the choice of a GNU | self-reference, n. - See self-reference  
generation on a dual AMD   | 
Athlon!|

Re: Fully introspectable Code objects?

2005-05-29 Thread Luke Palmer 
On 5/29/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
 Hi,
 
 while responding to nothingmuch++'s post function signatures?, I
 thought that it'll be great if Code objects were fully introspectable.
 
 I.e.:
   foo.statements; # List of statements
   foo.statements[0]   # First statement
   foo.statements[2] = ...;# Statement modification?
 
 And all objects returned from the introspection methods should stringify
 appropriately, so that...
   say ~sub { 42 + $^a };   # prints
   sub ($a) { return 42 + $a; }
 
 Is this going too far?
 Is this wanted?
 Is it useful?

I think it would be useful.  It's one of those features that less than
1% of people will ever use, but will allow the implementation of a
module that 99% of people use.

However, You can't really access it statement by statement and make it
useful.  You have to track scope enters and exits to keep track of
names, and you have to look inside the statements to see what they're
doing.  And it may be impossible to find statement boundaries from
pure bytecode.

A better way to do this would be to save parse trees along with the
code object.  One may not want to do this, however (for instance, for
code obfuscatory purposes, or for plain old memory footprint), so we
should enable it by some pragma:

use save_parse_trees;

And then we can use the eventually existing parse tree introspection
interface that we already know.

Luke