Dan Sugalski wrote: > > int perl6_parse(PerlInterp *interp, > void *source, > int flags, > void *extra_pointer); Given that other things may want to be streamable in similar fashion (eg the regular expression engine), why not have a PerlDataSource union or somesuch that encapsulates all of the possibilities of the final three arguments? Or put all possibilities into a PerlIO*? That gives direct support for compressed source, source streamed over a network socket, etc., with a more common framework than PERL_GENERATED_SOURCE. Things like PERL_CHAR_SOURCE meaning nul-terminated char* sound unnecessarily specific. Also, you gave two options: nul-terminated and length-first. What about a "chunked" encoding, where you get multiple length-first chunks of the input (as in HTTP/1.1's Transfer-Encoding: chunked, for one example of many)? Or are nuls explicitly forbidden in source code? And, in a related question, the above interface appears that you call perl6_parse once. Will this be good enough, or do you want to have a PerlParseState* in/out parameter that allows restarting a parse once you get more of the input available? (With this, you don't need an explicit chunked encoding, since the caller can deal with that without being required to buffer the whole thing in memory before calling perl6_parse.) Or would that go into the PerlInterp too? And finally, how do I get the output out of the PerlInterp? Is it stored under some variable name, or does the PerlInterp start out empty and gains the parsed syntax tree as its only syntax tree, or ? (The latter sounds messy if the PerlInterp is also running code, code that wants to call some standard utility functions implemented in Perl.) Maybe I'm not making sense.Thread Previous | Thread Next