On Wed, 2005-03-30 at 17:09, Luke Palmer wrote: > Aaron Sherman writes: > > What I do not think should be allowed (and I may be contradicting > > Larry here, which I realize is taking my life in my hands ;) is > > violating the compile-time view of the "static" type tree. > > That sentence is getting pretty C++-derived-like,
I think you mis-read what I wrote, and it was in a context that flowed from previous messages. I was referring to the part of the type tree (multi-root, directed, acyclical graph) which I had deemed to be "static" for the sake of handling interfaces sanely at compile-time. Hence the scary-quotes on "static", as we were not in agreement on that point. > 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. Even Ponie cannot truly be as dynamic as vanilla Perl 5. 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. I like Perl 5, but Perl 6 is not Perl 5... we have to be willing to accept that there are trade-offs for the features we've added. One possible trade-off is increased difficulty in debugging code. One possible trade-off is slightly less dynamic code. Your other message: On Wed, 2005-03-30 at 17:15, Luke Palmer wrote: > aron Sherman writes: > > It's valid because it's a function call on a code ref. In that case, the > > compiler has to hand your request off to the run-time to check the > > vtable of $.code. Clearly that's a special case. I may have missed > > context at the start, but are we worried about the special cases or the > > general case or the implications to the general case of the special > > cases? > > Okay, now we're starting to talk past each other. I /think/ Thomas > orignially suggested that we use type inference to determine whether to > lvalue cast an argument or not, which is what I got all worked up about. > I'm saying that you can't determine that kind of thing in general at > compile time. I'm all for an optional strong type system, as long as it > remains optional and mixable (so static things and dynamic things can > play nicely together, whether the module is static and the user dynamic > or vice-versa). Ok, so let me start from that point and ask a question: When the Perl 6 compiler sees: my X $a; $a.m(1); What should it do? Options: * Accept the method call regardless of the definition of X * Accept the method call if it matches the signature from X * Accept the method call if {magic($*INTERP)} Not to be pushy or anything, but please pick one and if it's the last, we can start to have a conversation about what that line-noise at the end actually does. ;-) -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback