Aaron Sherman writes: > > Please think carefully about how dynamic you want Perl 6 to be.... > > > Dynamic is good, but there's such a thing as too much of a good thing. > > > > We'd like Perl 6 to be as dynamic as Perl 5. > > We'd think that is impossible. Perl 5 had full control of the > run-time, Perl 6 does not.
Like hell it doesn't. Parrot is designed to support Perl 5. Perl 6 can do all the fancy stuff that Perl 5 did. If the Perl 6 compiler runs in Parrot, then it can control Parrot as it compiles, and reap information from that as it compiles. Parrot can easily redefine stuff on the fly and eval code at runtime. I don't see what "full control of the run-time" Perl 5 has that Perl 6 won't (if you have something specific in mind, enlighten me please). > What's more, Perl 6 introduces types, mmd, function signature > overloading, operator overloading and a host of other features which, > combined with the level of dynamism found in Perl 5 would seem to me > to lead to a compiler which cannot assist the user in writing > debuggable code. You keep mentioning this thing "debuggable code" and saying that adding dynamism impairs it. I'd say that Perl 5 is debuggable; I can certainly debug it. The kinds of modules that I work on introduce types and mmd, where Perl 5 already had operator overloading. I don't understand how adding dyanmism impairs debuggability[1]. The reason that types and MMD can be introduced into Perl 5 is because it's so dynamic. We, as language designers in 2005, can't possibly know what will be to us as MMD is to perl 5, but we want module writers to be able to implement it, whatever it is. Sorry I'm getting so worked up here.... It's just that in designing the next generation of a language that I cherish for its dynamism and freedom, I don't like the idea of restricting that in the interest of... whatever the interest is in (I can't actually tell with this argument). I think what Perl 6 can offer us over Perl 5 in terms of "safety", on a very feature-removed level, is much more comprehensive compile information available to the program. We could easily leave out the static type system from Perl 6 (not that I actually want to do this), and a module that implements it would be a heck of a lot easier to write than a module that implements it in Perl 5. Perl 6 gives you so many levels of control: lexical syntax control, hooks for everything you can dream of, possibility of generating pure parrot code inline, continuations (which help in writing a debugger), that I can't fathom how this could less debuggable than Perl 5. If you want to see when something, anything at all, is happening, stick a debugger hook in there. The more "static" we make our language--the less dynamic we allow it to be--the more debugging power we're taking away from the programmer. The lose of making things dynamic is that the compiler can't make as many assumptions, but Perl 6 allows many ways to tell it when it can make assumptions. As chromatic said, the programmer usually knows when the compiler can make assumptions better than the compiler does anyway. Whew... Okay, how can I turn around my rant and make it say something productive? I probably can't tonight. Nice yelling at you. :-) Luke [1] It might in a traditional debugger, but we are free to write our debugger in the extremely dynamic Perl 6, running it right alongside our program with all of our introspection needs at hand. If our debugger isn't good enough, we have the tools to write a better one. And for people like me who don't use the perl debugger, but who prefer print statements and Data::Dumper diagnostics, more dynamism implies more debugging power, not less.
