Re: Re: Re: Apocalypse 12

[fireartist]

in reply to Re: Re: Apocalypse 12
in thread Apocalypse 12

I've been looking forward to A12 for a while and I don't think I'm disappointed. - There's plently of stuff I haven't grokked yet - but the stuff I do really excites me.
The only concern I have at the moment, is the many references to compiler optimizations, as below...

It might be objected that this will slow down the parameter binding algorithm for all methods favored with an implicit *%_, but I would argue that the binding code doesn't have to do anything till it sees a named parameter it doesn't recognize, and then it can figure out whether the method even references %_, and if not, simply throw the unrecognized argument away instead of constructing a %_ that won't be used. And most of this "figuring out" can be done at compile time.

Will Perl6 not still have eval? - Will this not have an impact on any compiler optimizations that I don't explicitly ask for?
e.g. What if the above method's 'extra' arguments are thrown away, but auto-genereated code inside an eval tries to reference it? How can the compiler ever be sure enough to make that optimization except in the most trivial example?
method foo { return 1 }
However, I don't know a thing about compilers, so I don't know what I'm talking about - just giving you feedback on what I'm "troubled by" ;)

[TimToady]

Yes, Perl 6 will certainly have eval, and yes, it will certainly disable certain kinds of optimizations--just as it does in Perl 5. That's the nature of the beast. And if you're going to compile a program for your PDA, the size of the executable may grow dramatically if you use eval, since it then has to include the compiler.

It's just that eval, like goto, is the most general thing in its class. You never want to use either of those when there is a more specific construct that does what you want. Just as we've added various controlled forms of goto over the years, we've looked at the various uses of eval over the years and abstracted out various common operations like aliasing, symbolic references, and closure generation.

As for all the references to optimizations, don't sweat it. It's something language designers and implementors are supposed to worry about, and that concern leaks through at times. But most users shouldn't have to worry about it, at least until they have a bit of code they need to make run faster.

[jonadab]

The block form of eval (like your example) can be parsed at compile time along with everything else. I think where the optimizer is going to have to be careful is if you use the string form of eval. In that case, some stuff just won't get optimized that otherwise could be. So the performance-is-vital people will be telling us not to use string eval, and I can safely ignore them if I don't care about optimization :-)