Exception handling

[Jose E. Marchesi]

> Paul and list,
>
> On Sat, Sep 19, 2026, 11:16 Paul Wolneykien <manowar@altlinux.org> wrote:
>
>> On Tue, 8 Sep 2026 23:47:39 +0300
>> Paul Wolneykien wrote:
>>
>> > ...
>> >   3. The INI reader is implemented as a special case of the generalized
>> > transput and the position value it uses is "section, l, c" not "p,
>> > l, c". The original transput with "p, l, c" in this case is also a
>> > specialization of the generalized transput layer -- a specialization to
>> > deal with "paginated Algol 68 text" file format. By generalized layer I
>> > mean code that searches for patterns in text and also checks boundaries
>> > of text structures (i. e. "logical end") but the patterns it searches
>> > for are not hardcoded. It incorporates the logic of the original
>> > transput but not the special meaning of FF and LF chars. It would also
>> > use the concept of EXCEPTIONS instead of the limited set of predefined
>> > "on_(logical|physical)_*_end" procedure names, I suppose.
>>
>>   Hi! There also was a disguised question about (planned?) exception
>> handling support in GNU Algol 68. Currently, I can't find anything
>> about exception handling neither in ga68.texi nor in ga68-internals.texi.
>> If you think the topic worth discussion, it's better to start a new
>> thread.
>>
>
> I'm on vacation so this is a brief answer...

Enjoy your time off! :)

> The Revised Report defines exception handling in transput, detecting such
> things as end of line, end of page, end of file, bad character and maybe a
> few others that have slipped my mind.
>
> In my experience end of line is especially important when reading lines as
> strings.

There were at least three different proposals for an exception handling
mechanism for Algol 68, all of them published in the Algol Bulletin:

  AB49.4.1  C.H. Lindsey, A Proposal for Exception Handling in ALGOL 68.
  AB49.4.2  Martyn Thomas, An Exception-Handling Mechanism for ALGOL 68.
  AB52.4.2  G.S. Tseytin, And Exception Handling Proposal for ALGOL 68.

The two alternatives published in AB49 were the result of the work of
the same subcommittee (or a working group, whatever) and were similar,
but with some important differences.  Tseytin's later proposal takes
into account the modules system.

Some notes on these proposals:

- Lindsey's proposal is suitable to be implemented in existing compilers
  with minimum modifications, restricted to the run-time.  It is based
  on a new opaque mode Exception:

    mode [[aleph]] Exception = ...;

  Values of that mode are created with a procedure "new_exception", and
  they are raised with the operator RAISE:


    Exception singular = new_exception;

    proc gauss = (ref[,]real a, ref[]real rhs) void:
    begin
          ...
          if ...
          then RAISE singular fi;
          ...
    end;

  For catching and handling raised exceptions, a new mode Trap is
  defined:

    mode Trap = struct (Excetpion exc, proc void handler);

  As well as a new procedure "handle":

    proc handle = (proc void user_program, []Trap traps)void

  This procedure is more often than not called with in-situ arguments,
  like in:

    [1:n,1:n]real matrix, [1:n]real r;

    handle (void: begin ...
                        gauss(matrix, r);
                        ...
                  end,
            Trap (singular, void: (puts ("matrix was singular"),
                                   goto next_case)));

  Note how the single Trap argument is rowed to a multiple.  It is
  possible to specify handlers for more than one exception by passing a
  multiple of Traps to "handle".

  Note also how the "goto" mechanism becomes crucial in order to come
  back from the handlers.

  Lindsey's proposal is not compatible with the existing "exception
  mechanism" defined for transput in the RR (on_WHATEVER).

  Lindsey's proposal includes a full formal description.

- Thomas' proposal requires more extensive modifications to the
  compiler, and consequently it provides a more integrated feeling to
  the programmer.

  As in Lindsey's proposal, an opaque mode Exception is added, as well
  as a constructor "new_exception".

  Raising exceptions is performed by calling procedures:

  Then it defines a few standard procedures:

     proc raise = (Exception e) void: ...;
     proc reraise = void: ...;

  Raised exceptions are catched and raised by handlers which are
  installed in some given range by an "on" procedure:

     proc on = (Exception e, proc void l) bool: ...;

  Example:

     begin on(overflow, overflow_handler);
           on(bound_check, bound_check_handler);
           ...
           if too_big then raise (overflow) fi;
           ...
           exit
           overflow_handler:
             ...
           exit
           bound_check_handler:
             ...
     end

  Note how in the example the labels "overflow_handler" and
  "bound_check_handler" are procedured into proc void.  Again, in
  practice this exception handling mechanism relies on non-local jumps
  in order to exit the handlers.  The use of completers in the serial
  clause is nice and convenient.

  This proposal is compatible with the existing "exception mechanism"
  defined for transput in the RR.

  Thomas' proposal does not include a formal description.

- Tseytin's proposal is the Soviet proposal.  It requires further
  modifications to existing compilers, and takes into account the
  modules system (that we use in ga68).

  Unlike the previous proposals, exceptions are not modes, but a new
  construct exception-declaration is introduced instead:

     module Stacks =
     def
         exception (Stack)void stack_underflow;


     fed

  The exception declaration above defines an exception
  "stack_underflow", and also the mode of the routine handling that
  exception, which in this case is (Stack)void.

  A handler declaration then "redefines" the exception declared above by
  providing the actual handling routine.  This is done with the new
  construct handler-declaration:


     module Stacks =
     def
         exception (Stack)void stack_underflow;


         on stack_underflow: (Stack s) void:
            (puts("alas!"); abort());
     fed

  Finally, the so-declared exception is raised by using another new
  construct exception-call:

     module Stacks =
     def
         exception (Stack)void stack_underflow;

         pub proc pop = (Stack s) int:
            (... raise stack_underflow (s) ...);

         on stack_underflow: (Stack s) void:
            (puts("alas!"); abort());
     fed

  The exception handler can be re-defined any number of times by using
  additional handler-declarations, like for example:

     access Stacks
     begin
           on stack_underflow: (Stack s) void:
              (... goto underflow; ...);


           underflow: ...
     end

  Note how the exception-declaration gets publicized by the module.  The
  example by Tseytin seems to imply all exceptions get implicitly
  publicized, but I think that can be improved:

        pub exception (Stack)void stack_underflow;

  Tseytin's proposal has a formal description and intends to complement
  the MR (modules and separated compilation).  It also includes amends
  to the transput definition in order to be based on the proposed
  mechanism.

So what would be the best for GNU Algol 68?  Of the three proposals, IMO
it the Soviet proposal that we should carefully examine and base upon,
for several reasons:

First, we _do_ implement the modules system.

Second, we are not constrained on how much (or how deep) existing
compilers will have to be altered in order to implement the exceptions
system.  As of today, we only care about ga68, which we develop.

Third, Tseytin's proposal is more elaborated than the earlier proposals,
which were preliminary and RFC in nature.

Fourth, Tseytin's proposal is suitable for several interesting
generalizations that he himself discusses in his article.

We shall definitely discuss about this it the GNU Algol 68 BoF in
Cauldron in a couple of weeks.

Opinions?