develooper Front page | perl.perl6.language | Postings from June 2001

deferred FETCH called "tasty"

Thread Previous | Thread Next
From:
David L. Nicol
Date:
June 12, 2001 13:58
Subject:
deferred FETCH called "tasty"
Message ID:
3B2681C5.1F7B914@kasey.umkc.edu

I think I'm repeating what has been said already but here goes.
After sending this I'm breaking for a sandwich. :)
 

for database data, the problem domain is limited sensibly. We want
to defer as many lookups as possible, so they can be sent as a bunch
rather than sent one by one, and we would like this action to be hidden.

We can't simply tie in the perl5 sense, because tiedness does not persist
accross assignment.  So we need to either modify Assignment to allow more
than
value to get assigned, or we need to pass around something -- a magic
coderef,
perhaps -- that can hold a deferred expression -- and define certain
criteria
that trigger the expedition of the deferred expressions. The unjamming.  

We only mark the FETCHes that are worth deferring as special.  We do this
by having a new kind of internal SV that tastes like an SV but really
refers
to a coderef, which will return the SV when it is run.  

Perl5 scalars can hold codrefs, but the programmer needs to explicitly run
them.

All changes to data are done with The Assignment Operator, that
gives us one common point to twiddle when we twiddle things. 

Assignment knows about these, umm, "tasty variables" and any expression
involving
a tasty returns a tasty -- another deferment -- instead of a scalar.  Since
this is done by Assignment, the only way a side-effect could escape is if
the side-effect does not use the Assign interface.

so, a tasty variable holds a coderef which will return a scalar.  The
implications
of C<use tasty> would be, all expressions which might have a tasty in them
get expanded to something like:

	EXPR rewrites to: ( has_tasty(EXPR) ? bless(sub { EXPR },tasty) : EXPR )


The other side of the coin is a "swallowing context," (Simon C. will refer
to
this as a "gag reflex") which is, for database purposes, something that
triggers
all the deferred keys getting rolled up into a SQL query and the values
returned
inserted into the appropriate tasty vars so they become normal scalars
again,
either immediately or on next reference to them.  I guess every tasty knows
what it is waiting for, and as soon as that data arrives a flag would be
set.

Conditions are swallowing contexts, as are output statements.  Reaching a 
tasty depth limit might also be a swallowing context.


Hope this has helped.  I'm definitely going over to the Yello Sub on Main
street
and ordering a "torpedo" now.




"Daniel S. Wilkerson" wrote:
> 
> I think you could only delay function calls automatically like this if you
> could ensure that they are truely functional.  That is, their output must
> depend only on the arugments given and must have no mutation
> side-effects.  It seems to me that this is hard to guarantee in Perl, even
> for the compiler.
> 

> > a compilation mode in which all expensive accesses get deferred until



--
David Nicol
The feet that kick out the jams must be defined.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About