If memory serves me right, James Michael DuPont wrote:
> > JVM had a LineNumberTable and VarNameTable for debugging which were
> > declared as ``attributes'' to each method in the .class tree.
> >
> > I suppose VarNameTable is totally irrelevant for Parrot ...
>
> I dont know that, what is it? Variable name table? If so, i think it
> might be good for debugging.
Mapping between local vars and variable names ... because JVM has unlimited
(well virtually unlimited) local vars, this works for the JVM. But since
Parrot has only 32 registers , they get re-used for local-vars .
I think using IMCC will in general mess around the registers numbers for
the temporaries. So it doesn't make sense for Parrot to have a VarNameTable.
> > I think Parrot is going to *need* reflection operations :) ...
> > You might be able to extract information like you do with C# ,
> > with reflection looping over the methods.
>
> You might want to run C# in parrot, then you need it.
Not really for C# support only ... Dynamic invocation will need it...
<?php
$a="foobar";
$a(); // get method name "foobar" from global scope, run
?>
Something of this sort will need to occur .. C# is much easier as you
already know what all types/method there might be and there's no dynamic
member lookup :).
> I think it is meta-data, all information about the bytecode that might
> be interesting to a person, to understand what a give bytecode is and
> means, it's context, meaning, usage, and all that. it is all meta-data.
You could argue about that , but IMHO except the basic Reflection stuff
and debug information , all the other itty-bitty details are useless for
the engine . Better keep it in a seperate file ?. (and build a cool
bytecode analysis tool as well :)
> > .line 42 "life.fubar"
>
> Again, nice to meet you again Mr. Victory,
That's quoted off my fubar-to-IL compiler ... (that's what we call
the f'uped beyond recognition pascal clone we ``implement'' in our lab).
Cheerio,
Gopal
--
The difference between insanity and genius is measured by success
