🚀 go-pugleaf

I'm interested in Grandi's comments about signal/exception processing in
PL/I.   I've spent slightly more time programming PL/I (on Multics) than C
(on UNIX and DOS), so perhaps I'm biased, but...

With the possible exception of stack unwinding (cleanup condition)
which is hairy under the best of situations, I've found PL/I's signal
processing both fully functional and comprehensible.  (The
difficulties in correctly handling cleanup conditions in Multics PL/I
are well documented and well-understood by proficient Multics
programmers.)

Signal processing is more a function of the operating system than it
is of the programming language being used.  I can't imagine a tenable
argument for SysV's signal processing in C (besides, of course,
implementation efficiency, which doesn't hold water for me).  I seem
to remember a quote from Dennis Ritchie (I think--excuse me, Dennis,
if I'm wrong) that suggested that UNIX signals were not designed to
convey any information:  signals were meant to be either noticed or
ignored (sort of like moving faster than the speed of light, eh?).
Berkeley signalling sematics are somewhat better. 

With a well-defined (though perhaps implementation dependent) set of
system signals and the ability to define signals in the users'
namespace, PL/I offers the programmer complete, determinsitic control
over the handling of "exceptional" events.  (To those who aren't
familiar with Multics, you might also find it interesting to note that
signals can be both defined and handled at command level.)

I'm not terribly interested in involving myself in a religious (or
religiose) argument here, but as for me and my house, I shall long
miss PL/I's signalling semantics.