dukeleto: what I'm getting at is that there is no more info that can be included at the point of error. Our exceptions system is lacking when it comes to errors originating from C, and our API is lacking in handling those exceptions.

nwellnhof: not at all. '.sub 'main' :main; $S0 = freeze $P0; say $S0; .end' what "file" does that come from? the program that created it, which has no way of knowing the frozen string will be output or that the string it is outputing is a frozen pmc, or the file I may or may not be piping the output to?

nwellnhof: I agree with that diagnosis. And the solution to making that error easier to debug would be (a) to have access to a C level backtrace or (b) for it to be possible to handle exceptions from c (so Parrot_gbl_set_config_hash_interpreter() could spit out something intelligent about the situation).

fbrito: C makes the distinction between variable declarations and code. Declarations start with a type and may include statements as initializers. However, once a line of code (which does not start with a type) has been hit, you cannot put another declaration line.

By June, I would like you guys to be capable of giving talks at conferences like YAPC or OSCON where you can say, "We promised to deliver these features/improvements in Parrot in these releases -- and we did."

atrodo: for a basic implementation I don't think it should be too hard. JavaScript objects are very Hash-like. We would need some kind of a ProtoFactory that we can put in a prototype and get out a new clone