Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mit-eddie!wuarchive!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: Newlines in prints
Message-ID: <123451@uunet.UU.NET>
Date: 20 Feb 91 21:10:16 GMT
References: <1991Feb20.155958.8027@uvaarpa.Virginia.EDU> <1991Feb20.172023.13416@convex.com>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 40

tchrist@convex.COM (Tom Christiansen) writes:
>
>Now, swrite may be a whole nother matter.

It certainly is.

I have often wished that fopen would allow you to treat a piece of
memory as a file. Sprintf/sscanf sort of do this, but only
temporarily. They grab an unused FILE struct, or _IOSTRNG into
the flags word, set the length to a large (32k) number, then
call fprintf/fscanf to do the work.

So the question is, how do we (further) overload the open function
to allow the creation of file handles which refer to strings? In
fact, to get LISPish, how do we create a filehandle which gets/puts
from/to a user defined subroutine?

At the risk of stealing from the legal filename user space

	open(FH,'$STRING')	opens $STRING for IO
	open(FH,'&FUNC')	calls &FUNC to get/put each char

So how do we know whether to read or write?
By the context the file handle is used in.

Functions are expected to return a character if given no argument,
else put the character they're given. Optionally, they could be
given a RW flag to tell them what to do.

Strings would grow and shrink as needed, and would be seekable.
One interesting way of seeking would be by matching. The seek
pointer would be set to the beginning of $1 if parens were used.

Both strings and functions would always be open for both read and write.
This solves the problem of '>&FUNC' conflicting with '>&2'.

One could select these kinds of FH's for writing. No swrite needed.
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane