Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1142 > unrolled thread

Is multi-level function return possible?

Back to article view | Back to comp.compilers

Contents

  Is multi-level function return possible? noitalmost <noitalmost@cox.net> - 2014-03-10 15:46 -0400
    Re: Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 05:20 +0000
    Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-11 13:04 +0000
      Re: Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 22:15 +0000
        Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-13 17:05 +0000
          Re: Is multi-level function return possible? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-03-14 01:28 +0000
          Re: Is multi-level function return possible? Ivan Godard <ivan@ootbcomp.com> - 2014-03-13 18:32 -0700
            Re: Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 20:27 +0000
        Re: Is multi-level function return possible? George Neuner <gneuner2@comcast.net> - 2014-03-14 02:39 -0400
          Re: Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 21:34 +0000
            Re: Is multi-level function return possible? Marco van de Voort <marcov@toad.stack.nl> - 2014-03-14 22:59 +0000
          Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-16 17:19 +0000
            Re: Is multi-level function return possible? Marco van de Voort <marcov@toad.stack.nl> - 2014-03-16 18:39 +0000
            Re: Is multi-level function return possible? Andy Walker <news@cuboid.co.uk> - 2014-03-16 19:45 +0000
              Re: Is multi-level function return possible? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-03-17 16:15 +0000
                Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 17:36 +0000
                  Re: Is multi-level function return possible? Andy Walker <news@cuboid.co.uk> - 2014-03-21 02:04 +0000
                    Re: Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-21 02:50 +0000
                      Re: design of PL/I, was Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-21 06:43 +0000
                      Re: design of PL/I, was Is multi-level function return possible? noitalmost <noitalmost@cox.net> - 2014-03-26 14:16 -0400
                      Re: exception catching in PL/I, was Is multi-level function return possible? "Robin Vowels" <robin51@dodo.com.au> - 2014-03-27 21:08 +1100
                    Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-24 17:06 +0000
                      Re: Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-24 20:01 +0000
                      Re: Is multi-level function return possible? George Neuner <gneuner2@comcast.net> - 2014-03-26 04:00 -0400
                        Re: Is multi-level function return possible? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2014-03-27 01:58 +0100
                          Re: Is multi-level function return possible? Stefan Monnier <monnier@iro.umontreal.ca> - 2014-04-07 14:48 -0400
                      Re: Is multi-level function return possible? Andy Walker <news@cuboid.co.uk> - 2014-03-26 12:16 +0000
                        Re: Is multi-level function return possible? Andy Walker <news@cuboid.co.uk> - 2014-03-26 17:34 +0000
                        Re: history of C, was Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-27 00:05 +0000
        Re: Is multi-level function return possible? Bakul Shah <usenet@bitblocks.com> - 2014-03-15 10:28 -0700
      Re: Is multi-level function return possible? George Neuner <gneuner2@comcast.net> - 2014-03-14 02:44 -0400
        Re: Is multi-level function return possible? Marco van de Voort <marcov@toad.stack.nl> - 2014-03-14 19:38 +0000
        Re: Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 21:36 +0000
        Re: Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 21:47 +0000
          Re: Is multi-level function return possible? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2014-03-15 13:34 +0100
        Re: Is multi-level function return possible? Ian Lance Taylor <ian@airs.com> - 2014-03-14 16:55 -0700
    Re: Is multi-level function return possible? George Neuner <gneuner2@comcast.net> - 2014-03-11 13:56 -0400
      Re: Is multi-level function return possible? federation2005@netzero.com - 2014-03-26 17:39 -0700
        Re: catch and throw, was Is multi-level function return possible? rpw3@rpw3.org (Rob Warnock) - 2014-03-27 04:23 +0000
          Re: catch and throw, was Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-27 05:44 +0000
          Re: catch and throw, was Is multi-level function return possible? Bakul Shah <usenet@bitblocks.com> - 2014-03-26 23:20 -0700
            Re: catch and throw, was Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-27 19:21 +0000
            Re: exception catching in PL/I "Robin Vowels" <robin51@dodo.com.au> - 2014-03-28 10:50 +1100
              Re: exception catching in PL/I Martin Ward <martin@gkc.org.uk> - 2014-04-16 14:32 +0100
            Re: catch and throw, was Is multi-level function return possible? mac <acolvin@efunct.com> - 2014-03-28 23:08 +0000
              Re: catch and throw, was Is multi-level function return possible? Ivan Godard <ivan@ootbcomp.com> - 2014-03-28 18:24 -0700
                Re: catch and throw, was Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-29 02:47 +0000
                  Re: catch and throw, was Is multi-level function return possible? Ivan Godard <ivan@ootbcomp.com> - 2014-03-28 21:32 -0700
                Re: catch and throw, was Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-29 03:38 +0000
                  Re: precise and imprecise, was catch and throw, was Is multi-level function return possible? Ivan Godard <ivan@ootbcomp.com> - 2014-03-28 22:12 -0700
              Re: catch and throw, was Is multi-level function return possible? Kaz Kylheku <kaz@kylheku.com> - 2014-03-29 02:07 +0000
                Re: catch and throw, was Is multi-level function return possible? Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-03-29 02:44 -0400
              Re: PL/I exceptions, was catch and throw, was Is multi-level function return possible? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-29 02:40 +0000
                Re: PL/I exceptions "Robin Vowels" <robin51@dodo.com.au> - 2014-03-30 01:58 +1100
        Re: catch and throw, was Is multi-level function return possible? George Neuner <gneuner2@comcast.net> - 2014-03-28 03:52 -0400
    Re: Is multi-level function return possible? Louis Krupp <lkrupp@pssw.com> - 2014-03-11 15:16 -0600
    Re: Is multi-level function return possible? noitalmost <noitalmost@cox.net> - 2014-03-15 12:21 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#1192 — Re: catch and throw, was Is multi-level function return possible?

On 3/26/14, 9:23 PM, Rob Warnock wrote:
> According to Gabriel and Steele in "The Evolution of Lisp"[1],
> Lisp 1.5 [early 1960s] had (ERRSET form), ...

PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
ON would catch it. REVERT to cancel the effect of ON. Web search
indicates it was defined in 1964 but implemented later. May be the
PL/I designered borrowed it from an earlier language/facility?

[toc] | [prev] | [next] | [standalone]

#1194 — Re: catch and throw, was Is multi-level function return possible?

Bakul Shah <usenet@bitblocks.com> wrote:

(snip

> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
> ON would catch it. REVERT to cancel the effect of ON. Web search
> indicates it was defined in 1964 but implemented later. May be the
> PL/I designered borrowed it from an earlier language/facility?

As mentioned earlier, some features of PL/I were implementations of
features of OS/360.

OS/360 has SPIE, Specify Program Interrupt Exit, where what they call
exit is what others would call an interrupt routine. If a program
interrupt occurs (fixed or floating point overflow, zerodivide,
illegal instruction, and such) it will call the routine at the
specified address. When that routine returns, it goes back to the
original program, possibly with registers or memory modified.

There is, then, the corresponding ON unit such as FIXEDOVERFLOW or
ZERODIVIDE.  Other exception conditions such as end of file, of even
end of page when the system counts lines on a page, can also have ON
units.

ON units stay in effect on entering different blocks, either a new
procedure or a BEGIN block. On exit from a block, any ON units on from
that block are unstacked. REVERT goes back to the one on entering the
current block.

It seems that when multitasking is used, ON units can also be
inherited by subtasks.  I am not sure at all what happens when you do
that, but I expect that it complicates the implementation.

-- glen

[toc] | [prev] | [next] | [standalone]

#1195 — Re: exception catching in PL/I

From: "Bakul Shah" <usenet@bitblocks.com>
Sent: Thursday, March 27, 2014 5:20 PM

> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
> ON would catch it. REVERT to cancel the effect of ON. Web search
> indicates it was defined in 1964 but implemented later. May be the
> PL/I designered borrowed it from an earlier language/facility?

PL/I provided the means to catch an exception, typically a hardware exception,
but not limited to them.
S/360 hardware exceptions included floating-point underflow, floating-point overflow,
division by zero, fixed-point overflow, and invalid decimal arithmetic.
A few of these exceptions could be turned on and off at the program level
(e.g., float underflow). Others such as an invalid decimal data interrupt could not be turned
off, and were taken by the operating system which in turn passed control to the
program's error handler.
Thus, the hardware exceptions implemented in PL/I were OVERFLOW, UNDERFLOW,
FIXEDOVERFLOW, ZERODIVIDE, and invalid decimal data.
Those implemented in software included CONVERSION, SUBSCRIPTRANGE,
STRINGRANGE, ENDPAGE, ENDFILE.
The user could introduce his own named conditions, and invoke them using a SIGNAL
statement.
ON statements established the action to be taken in the event of an exception.
SIGNAL statements were provided for testing purposes (so that you could check out
your exception-handler), and for invoking a user-defined condition.

Certain exceptions can be turned on and off at procedure level and at
statement level; hence the statement prefixes such as NOFIXEDOVERFLOW
and FIXEDOVERFLOW.  Other exceptions such as ENDPAGE cannot be turned
off, but the exception handler can be a user-written null operation.

[toc] | [prev] | [next] | [standalone]

#1222 — Re: exception catching in PL/I

The first programming language I ever used was BASIC
on a Data General Nova minicomputer, via a model 33 teletype.
Later, some VDUs were added (but still at 110 baud!).

This BASIC had the commands ON ERROR GOSUB and ON ERROR GOTO for error
handling, but also had ON ESCAPE GOSUB and ON ESCAPE GOTO.  The latter
commands provided the only available means to interact with a running
program while it was still executing.

This, plus the ability to move the cursor on the VDU, was enough for
me to write my first real-time interactive graphical moon landing
game. To fire the lander's engine, just mash the escape key!

--
			Martin

Dr Martin Ward STRL Principal Lecturer & Reader in Software Engineering
martin@gkc.org.uk  http://www.cse.dmu.ac.uk/~mward/  Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors:  http://www.gkc.org.uk  and  http://www.gkc.org.uk/gkc

[toc] | [prev] | [next] | [standalone]

#1198 — Re: catch and throw, was Is multi-level function return possible?

> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
> ON would catch it. REVERT to cancel the effect of ON. Web search
> indicates it was defined in 1964 but implemented later. May be the
> PL/I designered borrowed it from an earlier


Not quite the same. ON defined a handler invoked at the signal site. It
could attempt repair and return. more like an interrupt. However, the
typical handler did a non-local GOTO to bail out, clearing any calls
between the signal and the gone-to label.

I still think that the ability to resume can be useful.

The classic survey is Goodenough 1975
<http://www.cs.colorado.edu/~bec/courses/csci5535-s09/reading/goodenough-exceptions.pdf>

[toc] | [prev] | [next] | [standalone]

#1199 — Re: catch and throw, was Is multi-level function return possible?

On 3/28/2014 4:08 PM, mac wrote:

> Not quite the same. ON defined a handler invoked at the signal site. It
> could attempt repair and return. more like an interrupt. However, the
> typical handler did a non-local GOTO to bail out, clearing any calls
> between the signal and the gone-to label.
>
> I still think that the ability to resume can be useful.

Useful or no, the ability to resume requires retaining the illusion of
sequential execution. You have no idea how expensive, in power and
performance, that illusion is. And it's flat-out impossible on wide
issue machine such as VLIWs.

[toc] | [prev] | [next] | [standalone]

#1202 — Re: catch and throw, was Is multi-level function return possible?

On 2014-03-29, Ivan Godard <ivan@ootbcomp.com> wrote:
> On 3/28/2014 4:08 PM, mac wrote:
>
>> Not quite the same. ON defined a handler invoked at the signal site. It
>> could attempt repair and return. more like an interrupt. However, the
>> typical handler did a non-local GOTO to bail out, clearing any calls
>> between the signal and the gone-to label.
>>
>> I still think that the ability to resume can be useful.
>
> Useful or no, the ability to resume requires retaining the illusion of
> sequential execution. You have no idea how expensive, in power and
> performance, that illusion is. And it's flat-out impossible on wide
> issue machine such as VLIWs.

I suspect you're may be thinking about resuming the exact instruction with the
exact machine state where some exception occured.

That's not even necessarily the best, most useful way to resume.

It's good for virtualizing actions: simulating instructions which are not
implemented in hardware, misaligned memory accesses, or making virtual memory
work.

On some machines, resuming an instruction requires going back a few
steps and software-emulating the last parts of what happened, because
the state of the CPU pipeline is too big and too messy to store.

Restartable exceptions or conditions in a programming language do not
have to follow this "down to the faulting instruction" model of
restartability.

The model can provide restarts that do not go back to the expression
which signaled the condition, but are themselves special handlers.
The condition handle handles the condition being signaled, and then
the restart handlers, similar to error handlers, handle the choice of
restart.

Here is an example Common Lisp program, where we use the
INVOKE-DEBUGGER function as the error handler, and provide interactive
mechanisms in the restarts.  INVOKE-DEBUGGER shows us available
restarts and gives us a prompt.

The interaction is not necessary: protocols involving the choice of
restarts can be mechanized. Or the style of interaction can be
arbitrary: GUI dialog boxes, whatever.

(defun read-new-thing ()
  (format t "Enter a substitute thing: ")
  (list (read)))

;; process-things is a function that prints te items from a list,
;; but it dislikeso items which are the symbol :rotten.

(defun process-things (things)
  (dolist (thing things)
    (block :continue
      (restart-case
        ;; the protected expression which signals
        (if (eq thing :rotten)
          (error "rotten thing detected!"))

        ;; restart cases
        (abort ()
          (return-from process-things))
        (substitute-thing (new-thing)
          :report "Give me non-rottem item."
          :interactive read-new-thing
          (setf thing new-thing))
        (ignore-it ()
          :report "Skip the rotten item."
          (return-from :continue)))
      (format t "accepting thing ~a~%" thing))))

;; We ask process-things to rpocess a list of letter symbols,
;; with the rotten item embedded in serveral places.

(handler-bind ((error #'invoke-debugger))
  (process-things '(a b c :rotten d e f g :rotten h i :rotten z)))


Test run with CLISP. FOr the first rotten thing, we choose to restart
by substituting an alternative. For the second :rotten, we choose
to ignore it. For the third rotten, we choose to abort, so that
the item Z which follows is not processed.

As you can see, the system makes additional estarts available which
we did not code, one of which is to bail out of loading the entire file.

$ clisp -q -i restarts.lisp
;; Loading file restarts.lisp ...
accepting thing A
accepting thing B
accepting thing C

*** - rotten thing detected!
The following restarts are available:
ABORT          :R1      ABORT
SUBSTITUTE-THING :R2    Give me non-rottem item.
IGNORE-IT      :R3      Skip the rotten item.
SKIP           :R4      skip (HANDLER-BIND # #)
RETRY          :R5      retry (HANDLER-BIND # #)
STOP           :R6      stop loading file /home/kaz/test/restarts.lisp
Break 1 [3]> :R2
Enter a substitute thing: foo
accepting thing FOO
accepting thing D
accepting thing E
accepting thing F
accepting thing G

*** - rotten thing detected!
The following restarts are available:
ABORT          :R1      ABORT
SUBSTITUTE-THING :R2    Give me non-rottem item.
IGNORE-IT      :R3      Skip the rotten item.
SKIP           :R4      skip (HANDLER-BIND # #)
RETRY          :R5      retry (HANDLER-BIND # #)
STOP           :R6      stop loading file /home/kaz/test/restarts.lisp
Break 1 [4]> :r3
accepting thing H
accepting thing I

*** - rotten thing detected!
The following restarts are available:
ABORT          :R1      ABORT
SUBSTITUTE-THING :R2    Give me non-rottem item.
IGNORE-IT      :R3      Skip the rotten item.
SKIP           :R4      skip (HANDLER-BIND # #)
RETRY          :R5      retry (HANDLER-BIND # #)
STOP           :R6      stop loading file /home/kaz/test/restarts.lisp
Break 1 [5]> :r1
;; Loaded file restarts.lisp
[1]>
[Am I the only one who remembers the OS/360 S0C0 termination code? -John]

[toc] | [prev] | [next] | [standalone]

#1204 — Re: catch and throw, was Is multi-level function return possible?

On 3/28/2014 7:47 PM, Kaz Kylheku wrote:
> On 2014-03-29, Ivan Godard <ivan@ootbcomp.com> wrote:

>> Useful or no, the ability to resume requires retaining the illusion of
>> sequential execution. You have no idea how expensive, in power and
>> performance, that illusion is. And it's flat-out impossible on wide
>> issue machine such as VLIWs.
>
> I suspect you're may be thinking about resuming the exact instruction with the
> exact machine state where some exception occured.
>
> That's not even necessarily the best, most useful way to resume.

<massive snip>

In machine terms, you are describing throw/catch, not resume. It
happens that your catch does a programming-language-level resume, as
opposed to a hardware resume. However, programming languages consume
zero power; my note was about machines, which unfortunately do a bit
worse :-)

Even in your throw/catch, it is extremely difficult to provide a
consistent model of side-effects that have, or have not, happened at
resumption. Of course, the language level (which runs infinitely fast)
can say that the program state is memoized at try and restored at
catch.  That's not a recommended practice on finite machines though.

[toc] | [prev] | [next] | [standalone]

#1203 — Re: catch and throw, was Is multi-level function return possible?

Ivan Godard <ivan@ootbcomp.com> wrote:
> On 3/28/2014 4:08 PM, mac wrote:

>> Not quite the same. ON defined a handler invoked at the signal site. It
>> could attempt repair and return. more like an interrupt. However, the
>> typical handler did a non-local GOTO to bail out, clearing any calls
>> between the signal and the gone-to label.

>> I still think that the ability to resume can be useful.

> Useful or no, the ability to resume requires retaining the illusion of
> sequential execution. You have no idea how expensive, in power and
> performance, that illusion is. And it's flat-out impossible on wide
> issue machine such as VLIWs.

That is true, and was already true for the IBM 360/91.

But there are different kinds of exception.

There are software generated exceptions (even if the underlying source
is hardware) that can be resumed. As I noted previously PL/I had
ENDPAGE that allows one to print page headers during I/O operations. A
single I/O statement may produce multiple lines of output, and the
ENDPAGE may occur during that output.

CONVERSION (an illegal character in a numeric field) also can
be corrected and resumed.

But yes, resuming hardware exception is complicated. S/360 required
operands to be properly aligned. It was believe that Fortran required
COMMON blocks to be packed, without any padding, even if alignment
requirements were violated. The fix was an interrupt routine to copy
the operand to a properly aligned buffer, preform the offending
instruction, and then return.  That worked (though was very slow) for
most S/360 models, but not at all for the 360/91, which allowed for
out-of-order execution.  The address reported for the interrupt might
be nowhere near the offending instruction, and more instructions using
the data might have been executed.  Most languages now allow for
padding and data to be aligned.

On the other hand, VLIW is pretty much dead. (I have an actual RX2600
Itanium based system, though don't use it much.)

-- glen

[toc] | [prev] | [next] | [standalone]

#1205 — Re: precise and imprecise, was catch and throw, was Is multi-level function return possible?

On 3/28/2014 8:38 PM, glen herrmannsfeldt wrote:

> On the other hand, VLIW is pretty much dead. (I have an actual RX2600
> Itanium based system, though don't use it much.)

Alive and well and living with starlets in Vegas. "Starlets" is a
euphemism for "embedded"; TI, Philips and numerous other vendors will
tell you that rumors of the demise are greatly exaggerated. :-)

And wide-issue is coming to the general-purpose world too. The Mill,
while not actually a VLIW, is wide-issue like one.

[VLIW works great for signal processing if you know in advance exactly
the program you want to run, and better if you can tweak the code.
Please refer arguments about the merits of the Mill to comp.arch,
though.  -John]

[toc] | [prev] | [next] | [standalone]

#1200 — Re: catch and throw, was Is multi-level function return possible?

On 2014-03-28, mac <acolvin@efunct.com> wrote:
>> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
>> ON would catch it. REVERT to cancel the effect of ON. Web search
>> indicates it was defined in 1964 but implemented later. May be the
>> PL/I designered borrowed it from an earlier
>
>
> Not quite the same. ON defined a handler invoked at the signal site. It
> could attempt repair and return. more like an interrupt. However, the
> typical handler did a non-local GOTO to bail out, clearing any calls
> between the signal and the gone-to label.
>
> I still think that the ability to resume can be useful.

PL/I seems to have been influential in the design of Common Lisp conditions,
right down to the terminology such as "conditions" being "signaled".

  (defun func ()
    (signal 'error))

  (tagbody
    (handler-bind ((error (lambda (cond) ;; Like PL/I "ON unit"
                            (format t "condition ~s signaled~%" cond)
                            (go :out)))
      (func))

    ;; "ON unit" is REVERT-ed, in PL/I terms, out of the scope
    ;; of the handler-bind form.
  :out
    (write-line "out"))

Under CLISP I get the output:

  condition #<ERROR #x20D8F216> signaled
  out

If the handler lambda returns instead of executing the (go :out) form, then the
system continues the search for the next matching handler and if one is not
found, or all the ones that are fond and executed simply bail out, then
control returns to the (signal 'error), causing it to return nil.

I.e. the transfer of control to the handler isn't a non-local transfer;
the (go :out) is!

Differences from PL/I are obvious: the strict nested scoping of the binding
constructs (no REVERT statement equivalent), and the use of a class hierarchy
for searching for the best handler for a given condition's type.

When a condition is handled in Lisp, the non-local control transfer is
not usually a GO, but rather the invocation of a restart.

Code which signals a condition can provide restarts which inform the handlers
about possible ways of continuing. For instance, a "file doesn't exist"
type condition could have a restart whose semantics is "continue processing
the rest of the file list" and another one for "abort the whole operation",
a third one for "try that file again", or yet another for the action
"supply a different file name in place of the nonexistent one, and
continue from that file on."

[toc] | [prev] | [next] | [standalone]

#1206 — Re: catch and throw, was Is multi-level function return possible?

Kaz Kylheku <kaz@kylheku.com> writes:

> PL/I seems to have been influential in the design of Common Lisp conditions,
> right down to the terminology such as "conditions" being "signaled".

The current Common Lisp condition system is descended from the original
Lisp Machine Lisp condition system that was designed by guys who had
programmed in PL/I on Multics -- they were quite consciously borrowing
the terminology.

--
Alan Bawden

[toc] | [prev] | [next] | [standalone]

#1201 — Re: PL/I exceptions, was catch and throw, was Is multi-level function return possible?

mac <acolvin@efunct.com> wrote:

(snip on PL/I ON units)

> Not quite the same. ON defined a handler invoked at the signal site. It
> could attempt repair and return. more like an interrupt. However, the
> typical handler did a non-local GOTO to bail out, clearing any calls
> between the signal and the gone-to label.

One I remember, but maybe no-one does anymore. You can use ON ENDPAGE
to paginate output. When an attempt is made to print a line past the
end of the page (an attribute of printable output files) the ENDPAGE
ON unit is executed, which skips to the next page and prints any page
headers.  Then return and let the output continue.

ENDFILE, on the other hand, (on input files) most likely goes on to
process the data. It might be that you could close the file, open a
new one and continue on. I never tried that.

For CONVERSION, you can test the invalid character, and, if desired,
replace it with a different one.

For SUBSCRIPTRANGE and STRINGRANGE there likely isn't much to do,
maybe just print a message. You could go process something else, but
usually not much point in trying again.

Java's try/catch, on the other hand, does not have the ability
to fix up and continue.

-- glen
[ON ENDPAGE was probably to help convert COBOL report writer programs. It's
in the PL/I standard, not just an IBM-ism.  -John]

[toc] | [prev] | [next] | [standalone]

#1207 — Re: PL/I exceptions

From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
> One I remember, but maybe no-one does anymore. You can use ON ENDPAGE
> to paginate output. When an attempt is made to print a line past the
> end of the page (an attribute of printable output files) the ENDPAGE
> ON unit is executed, which skips to the next page

It actually doesn't do that.
In the absence of an ON-unit, the standard system action is to start a new page.
With an ON-unit activated, PL/I does not "skip[] to a new page".
The code in the ON-unit may print a footer for the current page.
The code in the ON-unit must then execute PUT PAGE explicitly (or  a PAGE option)
to start the new page, where a header (incorporating an automatically-generated page number
via PAGENO) can be printed.
When the ON-unit concludes, normal printing continues.

> and prints any page
> headers.  Then return and let the output continue.
>
> ENDFILE, on the other hand, (on input files) most likely goes on to
> process the data. It might be that you could close the file, open a
> new one and continue on. I never tried that.

Yes, you can do that, or even re-read the same file.

> For CONVERSION, you can test the invalid character, and, if desired,
> replace it with a different one.

Or you can examine the entire field, and replace some or all of the entire field.
You probably also want to print the bad field.

> For SUBSCRIPTRANGE and STRINGRANGE there likely isn't much to do,
> maybe just print a message. You could go process something else, but
> usually not much point in trying again.

What is normally done for SUBSCRIPTRANGE is to include in the ON-unit some
PUT statements that print the values of variables that are used for subscripts,
and possibly some other variables, so that you don't have to re-run the program
to ask the same questions again.

With STRINGRANGE, it's usual to continue execution, because after displaying
an error message, PL/I forces the SUBSTRing arguments so as to confirm to the rules
(i.e., so that nothing is out-of-range, and nothing can be damaged).
It would also be usual to include a print statement in the ON-unit to print values of variables
used in SUBSTRing references.

STRINGSIZE warns you that the destination of an assignment etc is shorter than
the characters or bits assigned to it.

For serious errors, the ERROR condition also is raised following the raising of the
relevant condition (e.g., SUBSTRIPTRANGE, OVERFLOW, etc).

[toc] | [prev] | [next] | [standalone]

#1196 — Re: catch and throw, was Is multi-level function return possible?

On Wed, 26 Mar 2014 17:39:25 -0700 (PDT), federation2005@netzero.com
wrote:

>On Tuesday, March 11, 2014 12:56:01 PM UTC-5, George Neuner wrote:
>
>> The modern term is "exception".  See also "non-local" control
>> transfer, exit and/or return, and "escape" or "backtracking"
>> continuation.
>
>Right, the contemporary (not "modern") [Note 1] notion is the
>catch-throw paradigm.

TouchC). However, the date of writing is part of the context of a
missive, and I think people reading - and particularly responding to -
anything found on the Internet needs to be aware of the post date.

But this is off-topic here in comp.compilers.
[Only sort of.  I get mail from googlegroups users arguing
with a message posted 20 years ago. -John]

>I like to think of it as the "cap and trap" mechanism.
>
>I believe it originates with Prolog in the 1970's, since (a) catch and
>throw are part of Prolog's library of built-in functions, and (b) the
>multi-level breakout has always been an integral part of its run-time
>system.

My understanding was that CATCH/THROW originated with MacLisp, though
IIRC it was roughly the same time (1971-72) as Prolog was introduced,
so there may have been some cross-pollenization WRT syntax.

In fact, MacLisp already had a non-local error exit form: ERRSET/ERR.
CATCH/THROW was introduced as an alternative syntax specifically for
non-error situations because programmers were abusing ERRSET/ERR for
all kinds of non-local returns.


>The idea may also be motivated, in part, by the Curry-Howard
>isomorphism, which relates the "AND", "OR" and "IF-THEN" connectives
>of Intuitionist logic respectively to the product, union and function
>types. When the scope of the correspondence is extended to classical
>logic, it connects Pierce's Rule to the catch-throw mechanism. Look
>under the Wikipedia entry, for instance, which also points to the
>call/cc mechanism of Scheme and to the related notion of continuation
>passing.

Very interesting! Thanks for the pointer.

George

[toc] | [prev] | [next] | [standalone]

#1146

On Mon, 10 Mar 2014 15:46:31 -0400, noitalmost <noitalmost@cox.net>
wrote:

>Is this a doable thing for a Pascal-like language that is meant to be
>compiled? I have a multi-level break which works within a procedure, but the
>return across procedure boundaries seems to add a lot of complications.
>
>I don't recall this being discussed in the dragon book, perhaps because it's
>just a silly idea. But implementing the multi-level break got me curious
>whether it's possible.
>[Sure, you can do it.  PL/I let you jump out of a routine and I think Algol60
>may have, too.  You just need to keep your stack frames sufficiently linked
>so that you can find the one you want and unwind everything below it.  Look
>at the way Algol and Pascal reference variables in blocks outside the current
>routine and you'll get most of what you need. -John]

What you're looking for sounds similar to the setjmp/longjmp feature
in C and exception handling in C++.  If you're going to attract C++
users to your language, the try/catch block would be a good thing to
imitate.

Unisys ALGOL has a TRY statement;  see
http://public.support.unisys.com/aseries/docs/clearpath-mcp-15.0/pdf/86000098-511.pdf
for details.

I believe that exception handling as it's usually implemented is
driven by the calling routine, while it sounds like what you want is
for a nested procedure to return from an outer procedure.  Unisys
ALGOL does at least some of this with a "bad" GO TO statement, which
branches out of one or more blocks.  If an outer procedure END
statement has a label, and if you branch to it from within a contained
procedure, you've accomplished your multi-level return.

Louis

[toc] | [prev] | [next] | [standalone]

#1165

On Tuesday, March 11, 2014 09:04:57 AM Anton Ertl wrote:
> Yes, in Pascal you can goto a label that is in a containing procedure
> or function, even across several levels.  That is a very rarely used
> feature of the language, and Wirth removed it (along with goto) from
> his later languages.

I had to go look that up. Yep, it's there in the ISO standard, as one of the
uses of goto. This is kind of like what I had in mind. I was thinking of a
prettier syntax, though:
procedure f() :
  procedure g() int :
    procedure h() :
      return from g 3;
    end h;

    h();
    nope();  # doesn't get called
  end g;

  x : int;
  x := g();
  print x;  # prints 3
end p;

The syntax meshes nice with my break stmt:
while {outer} x < 10 :
  loop :
    break from outer;
  end;
end;

It's a lot more restrictive than exeptions, and I'm not sure if has any use,
but it looks nice :)
The only potential use that comes to mind is:
procedure p() :
  procedure r() :
    cond : bool;  # some condition
    break from r if cond;
    r();
  end r;
end f;

f();

The break would cause a quick exit by blowing away all the intervening stack
frames from the recursive calls to r.

I'm assuming I can implement this without too much trouble, since it could be
done in Pascal. Is that true?
[I would think so.  See the next message. -John]

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.compilers

csiph-web