Ticket #905 (new RFC)

Opened 5 years ago

Last modified 4 years ago

[RFC] Deprecate Eval PMC

Reported by: allison Owned by:
Priority: normal Milestone:
Component: none Version: 1.4.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

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.

Change History

Changed 5 years ago by 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?

Changed 4 years ago by 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

Changed 4 years ago by 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).

Changed 4 years ago by 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

Note: See TracTickets for help on using tickets.