generator functions in another language
castironpi at gmail.com
castironpi at gmail.com
Mon May 5 23:28:29 EDT 2008
On May 5, 1:55 pm, "metaw... at gmail.com" <metaw... at gmail.com> wrote:
> On May 4, 1:11 pm, castiro... at gmail.com wrote:
>
> > There is no such thing as a 'frame' per se in C; byte code is
> > integral. As there is no such thing as suspended state without
> > frames, and no such thing as generators without suspended state.
>
> Well, for implementing generators there are alternatives to using
> frames + byte code. In CLPython generators are implemented with
> closures. (Which does not help much when it comes to reimplementing
> generators in C, alas.)
>
> - Willem
There's a process decorator to functions in a module.
[supposes]
@process
def datafile( processdict ):
processdict.modify( )
op= yield
op.call( ) in processdict
# op.call( ) in namespace
More simply:
@process
def datafile( processdict ):
processdict.modify( )
interaction_object= yield
invoke( interaction_object, processdict )
#or interaction_object.invoke( **processdict )
processdict.commit( )
Making each execution of process a self-modifying disk file.
Interaction_object could be binary or text. If text, we'd have a
cross-language executable, but I'm suspicious it wouldn't be vacuous
as a Python of Python composition: would other languages pass other
than Python programs?
I think relational databases are the only in there. In other words, I
think Python would make a wholly better stored procedure and query
language than those of databases. Certainly I'm suspicious that's
naivete speaking up; I question, would it? Is there more risk of or
opportunity for malicious execution? Simply put, can we get
primitives in to databases? What's an example of a [optionally real]
operation on the primitives that doesn't map pretty well into SQL?
How do you want to write base-case scenarios if they're going to be
literals?
More information about the Python-list
mailing list