From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!gatech!bloom-beacon!mit-eddie!ll-xn!cit-vax!ucla-cs!zen!ucbvax!MITRE-BEDFORD.ARPA!sdl
From: sdl@MITRE-BEDFORD.ARPA
Newsgroups: comp.lang.ada
Subject: Re: Exceptions as generic parameters
Message-ID: <8707061441.AA10450@mitre-bedford.ARPA>
Date: Mon, 6-Jul-87 10:41:47 EDT
Article-I.D.: mitre-be.8707061441.AA10450
Posted: Mon Jul  6 10:41:47 1987
Date-Received: Tue, 7-Jul-87 06:41:22 EDT
References: <8706291324.AA03730@mitre-bedford.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


Like Dave Emery, I have often wished for the ability to define a
generic that takes an exception as a parameter.   Making the generic
definition directly visible at the point of the generic definition (either
by scope or context specification) is *not* an entirely desirable
alternative, because it may be the wrong coupling.  You often want the
exception to be grouped with the code that raises it, not with the
code that contains potential handlers for it.

However, I am concerned about the possible ambiguities/aliasing that
generic exception parameters may introduce, and whether this poses
potential problems for compiler writers.  Consider:


    generic
      E: exception;
    procedure FOO is
      X : FLOAT;
    begin
      . . . .
      X := {expression raising NUMERIC_ERROR};
    exception
      when E =>   {some handler}  ;
    end FOO;


    procedure MY_FOO_C is new FOO (E => CONSTRAINT_ERROR);
    procedure MY_FOO_N is new FOO (E => NUMERIC_ERROR);
  

In MY_FOO_C, the expression raising NUMERIC_ERROR would cause a control
transfer to the end of FOO (no handler).  In MY_FOO_N, the expression
would cause transfer to the exception handler for E (bound to
NUMERIC_ERROR).  

This means that the control flow of the generic body could not be
entirely determined when the generic is compiled.  (This might also
cause some problems with optimization of exceptions.)  Rather, some
table-driven scheme would be needed that would resolve such control
flow ambiguities at instantiation time.

The issue is whether code that raises the predefined exceptions is
compiled & optimized the same way that user-defined exceptions are
treated.  If so, then generic exception parameters shouldn't be too
difficult.

Would any Ada compiler gurus like to comment?


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl