Dan Anderson wrote: > I'm curious how perl "compiles" functions internally. When the actual C > code (or ASM equivalent or bytecode or whatever Perl uses) for a > function is run, is there overhead to the function? Are functions > inlined? Does perl lazy compile functions? (i.e. functions never used > are never compiled and that is why errors suddenly pop up when using a > function for the same time).
Not exactly. Perl seems, at least using strict, to compile all functions in the file being processed. It also compiles any modules called. What it does not do is linking. That is, it does not hunt down definitions for functions being called until runtime. I don't know about Autoload, though. This may defer compilation. It doesn't seem to be on by default. I only see it when I am working with a module such as Tk, in the form of a "failed to Autoload ..." error. It's not really laziness. With a large library such as Tk, there will be hundreds of methods that could be associated with any given object. It woould be an incredible waste to load all of these for an object that will use only a couple. As for the tweaky runtime behavior of functions already compiled, this is a result usually of a lack of prototypes. Since Perl allows flexible parameters lists, there is no way to logically predict whether the arguments offered will match the requisite parameters. When prototypes are used, perl should catch and prevent most of these runtime errors by ensuring that there is a direct correspondence between the arguments and parameters. That still does not prevent simple logic errors or those arising from bad input, but it definitely narrows the error domain. Joseph > Thanks in advance from a curious mind, > Dan > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
