[RFC] Deprecate Eval PMC

[allison]

The result of dynamically compiling a string of source code should be an ordinary Sub or Packfile object, not a custom Eval object.

This ticket was split out from TT #448.

[coke]

This does not appear in DEPRECATED.pod - allison, do want this to go into the list for 2.3 so we can remove it after that?

[jkeenan]

grep -in EVAL DEPRECATED.pod

As of today it still does not appear in DEPRECATED.pod.

Allison, can you update?

Thank you very much.

kid51

[allison]

Yes, I'm still in favor of the deprecation. It's easy enough to decide what to do when the eval is a single subroutine, trickier when it's a whole list of subroutines. As much as possible, we want it to act similar to a normal compile, perhaps return a sub object corresponding to the :main sub of the eval (if there is one).

[pmichaud]

Just to present a possible counter-argument; one of the possible advantages of the current "return an Eval PMC" approach is that it's possible for a HLL to introspect the returned Eval PMC and do any additional linking or setup that may be needed on the newly-compiled subs. If compiling source code instead chooses to return only a single Sub PMC, we lose that capability.

In particular, in Rakudo the eval() function has to compile a string which may create one or more subs, and then set the :outer context on the things that come back.... and it's definitely *not* the Sub marked :main that gets its outer context set (nor should it be, as that sub is not the HLL mainline code).

Pm