Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: While learning PERL... a suggestion
Keywords: perl file learn suggest
Message-ID: <118879@uunet.UU.NET>
Date: 19 Jan 91 04:01:54 GMT
References: <1991Jan19.003519.23569@ux1.cso.uiuc.edu> <11115@jpl-devvax.JPL.NASA.GOV>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 40

In article <11115@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>There's one other possibility.  If you know the pipe is really a socket,
>you might be able to do a recv() with the MSG_PEEK flag and read it out
>non-destructively.  Likewise for streams, using I_PEEK.

If it wasn't so trivial to write a getchar/ungetchar pair
might ask Larry to hack in ungetc, possibly with no limit on pushback.

Which brings us to the question of what should go in perl?
An easier question might be "What's missing, compared to C?"

Going thru the syscalls I see trivial omissions, such as `mknod'
or `reboot' that can best be done by invoking "system", without
resorting to using syscall.

However, it is control over signals that I find most lacking.

It is unclear whether signals are reset upon being being caught
and whether it is blocked during signal handler execution. I
believe Larry deliberately avoided answering these questions
in order to avoid system dependencies.

Some day, POSIX signal handling will have to be hacked in,
along with finer resolution alarm timers.

I suppose setjmp/longjmp is out of the question?
Catch/throw/unwind protect?

Grep is mapcar, am I right?

>I'm afraid the yolk is on all of us.

Yeah, but can a blue man sing the whites?

>Larry

-- 

	Root Boy Jim Cottrell <rbj@uunet.uu.net>
	Close the gap of the dark year in between