Front page | perl.perl6.language |
Postings from March 2005
Larry Wall wrote:
> That's actually weirdly symmetrical with the notion that only subs can
> impose compile-time context on their arguments, while methods always
> have to assume list context because you have to generate the argument
> list before you can know which method you're going to dispatch to.
Sorry if it's only me, but I don't understand what this means.
I get, that at the call site of a sub, first of all the lexically
closest sub can be determined at compile time. This means its signature
is available and can be checked and imposed on the arguments---right so far?
Single invocant methods are defined inside classes. Thus the knowledge of
the compiler about their signature hinges on how well the type of the invocant
can be determined. If the data is insufficient this is---depending on compile
mode---either a static type error or dynamic lookup has to be compiled,
with an optional warning.
BTW, do method names have to be pre-declared? Or does the following just
defer the existence check:
sub blubb ( $obj )
{
print $obj.somemethod( "FirstArg", "SecondArg" );
}
What I want to ask is: is ".somemethod()" parsed purely syntactically?
And is there a compiler mode where this is a type error like "type Any
doesn't have .somemethod<Str,Str>"?
With multi subs and methods I guess a lexical definition is needed as for
subs. But that doesn't mean that all dispatch targets are known already.
Thus a dynamic built-up of the arglist and MMD is compiled. Right?
A very nice feature of the compiler here were to perform implementation
side checks when the complete program is loaded? This involves potential
ambiguity and absence failures.
BTW, how far down to pure byte code can Perl6 packages be compiled?
Too much off the mark?
--
TSa (Thomas Sandlaß)
Thread Previous
|
Thread Next