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