Larry Wall wrote:
On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote:
: Another possibility: make it work. Add a "delayed" parameter trait
: that causes evaluation of that trait to be postponed until the first
: time that the parameter actually gets used in the routine. If it
: never gets used, then it never gets evaluated. I could see uses for
: this outside of the narrow scope of implementing substitutions.
Tell me how you plan to do MMD on a value you don't have yet.
MMD is based on types, not values; and you don't neccessarily have to
evaluate something in order to know its type. Also, you don't
neccessarily need every argument in order to do MMD: if there's a
semi-colon in any of the candidates' signatures prior to the argument
in question, MMD stands a decent chance of selecting a candidate
before the question of its type comes up. Worst case scenario (a Code
object without a return type being compared to a non-Code parameter),
you can treat the argument's type as "Any", and let the method
redispatch once the type is known, if it's appropriate to do so.
That said, the real problem here is figuring out what to do if some
candidates ask for a given parameter to be lazily evaluated and others
don't. It would probably be best to restrict the "lazy evaluation"
option to the prototype's parameters, so that it always applies across
the board.
--
Consider this as another option: instead of a parameter trait, apply a
trait to the method prototype. With this trait in play, all parameter
evaluations are postponed as long as possible. If the first candidate
needs only the first two parameters to test its viability, only
evaluate the first two parameters before testing it. If the dispatch
succeeds, the other parameters remain unevaluated until they actually
get used in the body. If all of the two-parameter candidates fail,
evaluate the next batch of parameters and go from there.
This approach doesn't guarantee that a given parameter won't be
evaluated before its first appearance within the routine; but it does
remove the guarantee that it will be.
--
In the case of subst, there's an additional wrinkle: you can't always
evaluate the expression without making reference to the pattern's
Match object, which won't be known until the pattern is applied to the
invocant. In particular, closures that refer to $0, $1, etc. will
only work properly if called by the method itself, and only after $0,
$1, etc. have been set.
All things considered, the best solution for subst might be to treat
the timing of quote evaluation in a manner analogous to regex
evaluation.
--
Jonathan "Dataweaver" Lang
