develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_'read-only'?

Thread Previous | Thread Next
From:
Aaron Sherman
Date:
March 30, 2005 15:35
Subject:
Re: Parameter and trait questions - just how 'only' _is_'read-only'?
Message ID:
1112225707.7453.19483.camel@pps
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 <ajs@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About