Re: The external interface for the parser piece

Tom Hughes <[email protected]> writes:
>In message <[email protected]>
>        Dan Sugalski <[email protected]> wrote:
>
>> At 10:42 AM 11/29/00 +0000, Nick Ing-Simmons wrote:
>>
>> >FILE * is not a good idea. PerlIO * is fine.
>> 
>> The problem with that is we're potentially getting the filehandle from
>> something that isn't perl. Or so my thinking went at the time. Right
>> now I'm thinkng that I need to rethink things.

That was my point. The Parser API should stick to PerlIO * - which is 
an abstract interface. How that interface gets provided is none
of the _parser's_ business.

There is another side to this - perl itself (particularly on Win32 or 
other places where stdio is "broken") may not have a FILE * to give 
you - it may only have PerlIO *.

>
>That shouldn't matter so long as there's a simple way to create
>a PerlIO * from a FILE * or whatever.

Bleadperl work on PerlIO is teaching that it is not necessarily "simple" to 
convert one to the other. One can wrap a FILE * inside a PerlIO simply 
enough, provided that the provider then promisses not to touch it in 
anyway while perl is messing with it, but the FILE *-ness gets
exposed. For example there are issues with FILE *'s
'textmode' and PerlIO's crlf layer fighting. Unless we inherit perl5's
twin-IO * concept (which I would not recommend at this stage) there are also 
issues with bi-directional things like sockets.

It is (currently) much better to open a PerlIO * from the outset,
either from a pathname, or a low level "file descriptor" (what a
low-level descriptor is on non-UNIX is work in progress).

Now we should be able to clean that up some (even in perl5) but 
we don't want to expose all the mess to the _parser_ API.

If we say FILE * we _may_ have to say - FILE *, open in binmode, not 
line buffered, not to a socket on Win32, ... and a whole host 
of other gunk. And then (presumably) inside the parser wrapper do 
the right thing to turn it into a PerlIO * so we can use UTF8, 
CRLF, encode/decode etc.

Better (IMHO) to do that _outside_ the parser API under another 
committee's juristiction. 

>
>That's probably something that needs to be specific to different
>language bindings - if you're embedding perl in C++ you probably
>have an iostream, and if you're embedding in Java you'll have a
>Java stream object. In each case you'll want an easy way to create
>a PerlIO object from that.

Why not export the PerlIO API and have language call that?

But if not possible then we can write 

parse_FILE(FILE *x,...)

which takes the FILE *, wraps in in a PerlIO * calls the generic Parser
unwraps can cleans up and returns.

>
>Tom
-- 
Nick Ing-Simmons <[email protected]>
Via, but not speaking for: Texas Instruments Ltd.