Stevan Little <[EMAIL PROTECTED]> writes:
> On May 25, 2005, at 5:39 AM, Piers Cawley wrote:
>> One of the 'mental apps' that's been pushing some of the things I've been
>> asking for in Perl 6's introspection system is a combined
>> refactoring/debugging/editing environment for the language.
>
> Maybe I have been reading too much about Smalltalk meta-classes lately, but in
> doing some draft ideas of the Perl6 meta-model for Pugs, I realized that given
> a really solid class/metaclass introspection system and access to the
> interpreter level meta-meta-classes, it would be possible to easily write a
> class browser much like Smalltalk.
Yes. The application in my head looks very a Smalltalk environment. The way I
see it working is that the language itself has a bunch of minimal hooks that
get triggered by various phases of compilation etc. Your editor then becomes
something that instruments the compiler in such a way that loading a file for
editing compiles it, but the compilation process hangs populates the data
structures you need for editing. So, when you go to edit, say:
class Collection {
method inject_into ($self: $initial_value is copy, *&block) {
$self.each
:{ $initial_value = &block($initial_value, $_) }
return $initial_value;
}
}
You'd end up with a Class object which would have all sorts of interesting
things added to it, including collections of instance variables, class
variables, methods etc. Methods would have metadata about the environment in
which they were evaluated (so when you edit a method you could recompile it in
the correct environment), the file they're found in, their source code
(possibly attributed to allow for syntax highlighting), the resulting AST,
etc. Once you have such a rich set of metadata to hand, it becomes a simple
matter of programming to add all sorts of handy features, refactorings,
breakpoints, whatever...
The point being that you don't really need a massive amount of support from the
core language to do all this. At a pinch you can take advantage of the fact
that the grammar is replaceable and core classes are extensible (and if they're
not, you just stick them in boxes for the editor's purposes).
> And to extend that to also be a refactoring browser would require the
> meta-meta-class system to be able to generate and emit code, which, if we
> properly model the meta-meta-classes should also be fairly simple as well.
We've got eval for that. Assuming you can do eval with arbitrary bindings (and
if necessary you can drill down to parrot for it) you just do something like:
Class.can('fred').environment.eval($freds_new_sourcecode)
Of course, if you alter a macro you're going to have to reevaluate pretty much
all the source code, but so what?
> And of course all this is even simpler if the interpreter is written in Perl6
> (although the cyclical nature of that can be dizzying at times).
It really doesn't have to be. It'd be nice, but not necessary. You just have to
make sure you can extend the runtime using perl. And macros already do that.
> However adding debugging support to this is another matter all together, and
> it
> is only partially useful to the non-OO programmer.
Not that hard to be honest. The same instrumented interpreter techniques can be
used to write the debugger.
