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
