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

Re: return of copies vs references

Thread Previous | Thread Next
From:
Larry Wall
Date:
March 26, 2005 21:18
Subject:
Re: return of copies vs references
Message ID:
20050327051806.GB25664@wall.org
On Thu, Mar 17, 2005 at 07:21:18PM +0100, Thomas Sandlaß wrote:
: 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?

Yes.

: 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.

In general, most dynamic languages (including Perl 5) assume that it is
impossible to know all the method names even after normal compilation,
since new classes or methods can be added at any time.  Perl 5 even lets
you change your @ISA hierarchy on the fly, if you're willing to take
the performance hit.

: 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?

In standard Perl 6 this is pure syntax, and doesn't care whether
.somemethod exists yet or not.

: And is there a compiler mode where this is a type error like "type Any
: doesn't have .somemethod<Str,Str>"?

Potentially it could, but it wouldn't by default.  You'd have to
explicitly tell the compiler that you aren't adding any more classes
or methods.  But then you couldn't use any kind of an autoloader, and
plugable architectures become problematic.

: 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.

For various definitions of "complete".  Perl potentially runs a lot
of code at compile time and compiles a lot of code at run time.

: BTW, how far down to pure byte code can Perl6 packages be compiled?

That would depend on your definition of "impure byte code", I expect.

: Too much off the mark?

Compile-time type checking is just another thing we're trying to
make possible without actually doing it ourselves.  But it's not way
up there on the priority list.

Larry

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