Ticket #905 (new RFC)

Opened 12 years ago

Last modified 11 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 12 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 11 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 11 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 11 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.