Dan Sugalski wrote:
>
> At 04:39 PM 6/12/2001 -0500, David L. Nicol wrote:
> >
> >I appear to be suggesting that deferability be an add-on that causes some
> >rewriting to support itself, rather than an optimization to parse away
> >bothering with silly calculations that we will never see the results of.
>
> That's fine, and we may end up going that route. I'd rather not, as it
> either shoots the optimizer badly, or requires the generated bytecode to be
> a lot more complex. (Basically requiring two code paths depending on
> whether data's active or not)
If we know at compile time we don't have to generate the other one.
If the bytecode is late-rewritable we can put off generating the second
code path until we need it, although the pass to see if it is needed or
not still has to go in there.
I imagine the tasty module would allow any deferred datum to be designated
as from any of a number of "mouth" collections, each one associated with
a separate expensive data source -- i.e. SQL server -- they would have to
be marked as to if they had been swallowed, which means that expressions
containing them should be evaluated instead of further deferred.
Are deadlocks possible? Deadlock avoidance strategy would need to
be used if they are. When in doubt, swallow immediately.
> >Got to make the programmers worry about _something!_
>
> Sure, but why this?
I don't understand the situation you want to optimize. I think a
programmer
who would write:
sub loiter_after_generating_a_value {
my scalar retval = do something_that_generates_a_value;
do_something_without_side_effects;
do_something_else_without_side_effects;
return retval;
}
deserves to have their code run slower than someone else who comments out
the two something elses or sticks a goto in to hop over them.
You are saying you want to support the situation where something_else used
to have an important side effect, but doesn't any more, and in that case
the compiler can just skip it?
