Re: tasty db data
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?
Re: tasty db data
At 04:39 PM 6/12/2001 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > > David L. Nicol [made an akward metaphor with data as summer campers] > > This is a considerably less simple problem than you (and *definitely* I) > > might like. :( > >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) >Got to make the programmers worry about _something!_ Sure, but why this? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
tasty db data
Since I just proposed a new paradigm I'll try to apply it, before
darting down the hill and getting my sandwich.
Dan Sugalski wrote:
> > David L. Nicol [made an akward metaphor with data as summer campers]
> That's less easy than you might think. Quick:
>
>$bar = bar();
>
> is $bar active or not?
$bar is active, as in "perl's active data" by default. It would be
tasty only if bar() returned a tasty value.
> Or:
>
> my $foo;
> if ($bar) {
> tie $foo, Bar;
> }
>
> how about then?
use of $bar as a conditional would trigger "swallowing" which would mean,
from the point of view of the "mouth" which held $bar in deferment, time
to compose and submit and wait for the large SQL query.
> This is a considerably less simple problem than you (and *definitely* I)
> might like. :(
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.
Got to make the programmers worry about _something!_
--
David Nicol 816.235.1187
It's all a crossword puzzle to me
