On Wed, 2005-03-30 at 11:40, Luke Palmer wrote:
> No, I think I agree with you here. But what happens if you change
> you're second-to-last line to:
>
> my $a = foo();
> $a.meth() = 8;
>
> Perl 6 is both a statically typed language and a dynamically typed
> language, and the problems that I am addressing are mostly about the
> dynamic part.
The way I've always thought about that one (and perhaps I'm just
misguided) is that you're really saying:
my unknown $a = foo();
$a.meth() = 8;
And unknown does something strange (unique?) along the lines of:
class unknown is scalar, pragma::everything {...}
That is, logically, unknown allows you to use any interface (note that I
said "pragma" because sub-classes of scalar don't get this behavior),
but realistically, a compiler must simply throw up its hands on that ONE
type of variable and allow you to get away with nearly anything (and
leave it up to the run-time to use your vtable to discover the truth).
The feature you get here is that a compiler that wanted to spend hours
of compute-time validating your program COULD search every known
interface, and tell you:
Unknown method signature in dynamic call at line 100
or an even smarter compiler could say:
Method signature on line 100 unrelated to previous usage on line 98
That is, you called a method on line 98 that matches no classes above,
below or the same as the classes matched by the signature of the method
you called on line 100. This kind of "lint" checking would be very
handy, though I'm sure it would be too time-consuming for the general
"-w" case.
> > eval "use X";
> > my X $a;
> > $a.m(1);
> >
> > I think that's invalid too, but I'm not sure.
>
> Again, that's invalid in the static world, but it should work if you
> s/my X/my/. The kinds of type inferrence people are saying would solve
> our problems require us to infer code like this, which we can't do.
I think there, you are well justified in saying that you can try to get
away with it, but a compiler that's smart enough to realize that you
need a run-time loaded dynamic type to make it work should punt it. Of
course, that ASSUMES that auto-loading is a two-stage process with an
interface definition and a run-time code load. Given that, what you
wanted was auto-loading, not run-time string eval. Those are not the
same thing.
If you're doing code-generation at run-time ... huh, what happens, let
me think...
Let's say you generate this code from a specification of some sort:
class __c001 { method __m001(int $__i001) {...} }
__c001.new;
and then try to call:
(eval $generated_code).__m001(1);
Ok, that's good because eval returns the same unknown scalar type as a
bare my declares. I guess you can also taint anything that comes from an
eval and just avert your gaze... you'll have to taint objects that use
non-Perl6 object systems in the same way, anyhoo:
my $thing = Runtime::Python::re::compile('.*');
$thing.search('moo');
> There _is_ a way to do it, actually, but we need to really screw around
> with what kinds of things are inferred. In the case:
>
> my $a;
> $a.m(1);
>
> We assign the type "objects with an 'm' method that can take a single
> integer" to $a. This is a category of objects that spans many classes,
> and does not fit into a nice little tree. I think that before we take
> on such an idea, we should look for research about this kind of type
> inference.
Heh well, here's where we notice that Aaron reads and replies in series
by paragraph ;-)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
