Re: Orphaned Response

Re: Orphaned Response

[gjs]

I recently saw a demo of the Xinotech Program Composer, an advanced
syntax-directed editor.  It runs on IBM PC and AT, and supports
multiple views of your program.  That is, once a program has been read
or typed in, you can view it as Ada, as Pascal, as Fortran, as Cobol,
etc.  There are obvious limitations with respect to common language
constructs.  I have no idea how large a program it can handle.

Contact:
    Xinotech Research, Inc.
    520 2nd Avenue S.E.
    Suite 307
    Minneapolis, Minnesota 55414
    612-623-4879

I have no connection with Xinotech, except that I saw their demo.

    -- George Snyder -- Intermetrics, Inc. -- inmet!gjs --

Ada '88 musings

[stt]

Just to get a little meaty technical discussion going...
Here are some proposals for Ada '88, arising from
our use of Ada in building compilers, database managers, etc:

  1)  Support user-defined finalization for
      packages and limited types.
  2)  Support user-defined assignment for limited types.
  3)  Extend identifier visibility rules to eliminate need
      for most "use" clauses.

I consider (1) essential to using Ada for significant
systems programming, anytime multi-access or multi-tasking
exists in the program or the environment (to guarantee files
are closed, buffers are flushed, locks are released, storage is
reclaimed, etc.)

(2) is mostly a syntactic sugar issue, though any language
supporting the notion of abstract types ought to support it.

(3) is probably necessary for the upward-compatible
implementation of (2), to give correct visibility
characteristics to user-defined ":=".


One mechanism for implementing (1) would be as follows:

The "begin" of a declarative part would be extended
as follows:
   [  when end =>  STATEMENT_LIST  ] begin
The statement_list would be executed when the declarative part
is exited for any reason, after waiting for any tasks to complete.
Exceptions raised and not handled in the statement list would
cause the statement_list to be terminated, and the original exiting
action to continue.

In addition, a finalization procedure may be defined for
a limited type, with the following syntax:

    procedure "end"(OBJ: in out LIM_TYPE) is begin  ... end "end";
    
When such a procedure is visible (see discussion of (3) below), then
in addition to waiting for tasks to terminate, a block statement,
subprogram body, or task is not finished until each of the dependent
objects are finalized (by calling "end" on them).

Any exceptions raised and not handled by the "end" procedure
cause the procedure to return and processing continues with the
next "end" procedure.

For limited objects designated by access values, the "end"
procedure may be executed once no references remain, prior
to reclamation of the storage, but after termination of
all task components of the object.

Let me be the first to say that the proposed syntax is pretty
ugly, but user-defined finalization is so important that
in the absence of more creative suggestions, this would still
be worthwhile.

The implementation of (2) is pretty straightforward, stealing all
the rules from user-defined "=", except that the subprogram spec must be
of the form:
   procedure ":="(L : in out LIM_TYPE; R : in LIM_TYPE) is
   begin ... end ":=";

Restricting this to limited types is to eliminate confusion
with the many implicit assignments implied in legal
operations on non-limited types (e.g. aggregates, array assignment,
etc.).  These are the same as the arguments for user-defined "="
being restricted to limited types (with the same holes in the arguments,
presumably).

The problem with (2) is that built-in ":=" is "directly" visible
even when other implicitly defined operations (like "=") are not.
To avoid forcing everybody to "use" the defining package
of a limited type to get visibility on ":=" (or the horrendous
pkg.":="(a, b)), we come to:

The implementation for (3):
Add a third place to search for identifiers after consulting
"direct" visibility and "use" visibility -- "defining-package"
visibility.  Defining-package visibility would mean that
after consulting the "use"d packages, each package in which
the type of a parameter is defined is consulted for a subprogram/operator
definition.  Note that the package of the result-type is NOT included.

In fact, if more than one package is represented among the types
of the parameters, then it is guaranteed that at most one
of them could have visibility to all of the parameter types,
and hence only one of them could possibly provide a definition
for the subprogram/operator.

For example:
    x+y    Assume type of x is pkg_x.type_x and type of y is pkg_y.type_y
           and pkg_y looks like this:
	   
           with pkg_x;
	   package pkg_y is
	       type type_y is new integer;
	       function "+"(a:pkg_x.type_x; b:type_y) return type_y;
           end pkg_y

   Then it should not be necessary to "use" pkg_y for Ada semantics
to resolve "+" in x+y.
This should eliminate most of the need for "use" clauses.

All of these ideas are half-baked, but we still have 2 years
to finish the baking...

Tucker Taft
Intermetrics, Inc.
733 Concord Ave
Cambridge, MA  02138   (617) 661-1840

Re: Ada '88 musings

[stt]

Initialization may be specified for limited types which are
record types, by supplying default expressions for the components.
By nesting any type within a record (possibly discriminated), it
is possible to specify a relatively arbitrary initialization.

For example:
type lim(x : integer) is limited private;
 ...
type lim(x : integer) is
    record
        contents : exciting_type(x) := complicated_function(x);
    end record;

Re: Ada '88 musings

[Scott Pilet]

>   3)  Extend identifier visibility rules to eliminate need
>       for most "use" clauses.
> 
> (3) is probably necessary for the upward-compatible
> implementation of (2), to give correct visibility
> characteristics to user-defined ":=".
> 
> The problem with (2) is that built-in ":=" is "directly" visible
> even when other implicitly defined operations (like "=") are not.
> To avoid forcing everybody to "use" the defining package
> of a limited type to get visibility on ":=" (or the horrendous
> pkg.":="(a, b)), we come to:
> 
> The implementation for (3):
> Add a third place to search for identifiers after consulting
> "direct" visibility and "use" visibility -- "defining-package"
> visibility.  Defining-package visibility would mean that
> after consulting the "use"d packages, each package in which
> the type of a parameter is defined is consulted for a subprogram/operator
> definition.  Note that the package of the result-type is NOT included.
> 
> In fact, if more than one package is represented among the types
> of the parameters, then it is guaranteed that at most one
> of them could have visibility to all of the parameter types,
> and hence only one of them could possibly provide a definition
> for the subprogram/operator.
> 
> For example:
>     x+y    Assume type of x is pkg_x.type_x and type of y is pkg_y.type_y
>            and pkg_y looks like this:
> 	   
>            with pkg_x;
> 	   package pkg_y is
> 	       type type_y is new integer;
> 	       function "+"(a:pkg_x.type_x; b:type_y) return type_y;
>            end pkg_y
> 
>    Then it should not be necessary to "use" pkg_y for Ada semantics
> to resolve "+" in x+y.
> This should eliminate most of the need for "use" clauses.
> 
> All of these ideas are half-baked, but we still have 2 years
> to finish the baking...
> 
> Tucker Taft
> Intermetrics, Inc.
> 733 Concord Ave
> Cambridge, MA  02138   (617) 661-1840

In a large system effort, some other programmer may have a package
with a y and a "+" that would allow x+y.  The lack of a "use" statement
adds to the complexity for debugging and sets the system up for a disaster
in the future.  The existence of a "use" statement may be nice for small
Ada programs, but in a large project the use of it may add to the confusion.
"with"ing and "rename"ing ensures that the software engineer is positive
of where an identifier is from and what it is.  More errors will be detected
by the software tools used by the engineers in a large software project
following this type of methodology.  As a tool to aid the software engineer,
a compiler message suggesting some resolution of an undefined identifier,
operator, or procedure (etc.) is helpful, but a compiler allowing ambiguities
that are technologically preventable can be disaster.

scott pilet
--these statements are my own and not Boeing's

Re: Orphaned Response

[stt]

I am not sure I understand your point completely, but
I certainly agree that "use" visibility is bad news in
a large system.  I would prefer "use" visibility to
go away completely.   The presence of a feature like
"defining-package" visibility would make it largely unnecessary.
Unfortunately, upward compatibility requires that it be left in the
language, though perhaps it could be marked for eventual removal.

The advantage of "defining-package" visibility is that
the code-reader only need be aware of the package(s) defining
the types in the expression, rather than all possibly "used"
packages.  It also encourages the "abstract" type
approach, where the defining package provides the whole
story w.r.t. a type.
 -Tucker Taft

Re: Orphaned Response

[stt]

AND, OR, and XOR are defined on boolean arrays (whether packed or not).
If you have a great desire to apply these operators to Integers,
then you will have to implement them via pragma-Interfaced functions (in C
or assembler), or hope that your compiler supports packed boolean arrays
and Unchecked_Conversion between Integers and appropriately-long
packed, constrained, boolean arrays.

Re: Orphaned Response

[GOODENOUGH@]

USE_ERROR can be raised when an attempt is made to create or open an
external file.  In particular, this exception can be raised when certain kinds
of file I/O are not supported at all by an implementation.  It can also be
argued that NAME_ERROR can be raised if no I/O operation is supported (see
14.4(1, 4, 5).  I believe that compilers for embedded targets have been
validated even though they raised NAME_ERROR or USE_ERROR when any attempt
was made to create or open a file.
-------

Re: Orphaned Response

[GOODENOUGH@]

I noticed an assertion in this message that you can't jump out of case
statements with GOTOs, but of course, such jumps are allowed.  You can't
jump between case statement alternatives, though, and perhaps this is what was
meant.
-------

Re: Orphaned Response

[richw]

>>  Wrong conclusion.  If a language allows the program you describe
>>  then any implementation that behaves the way you're worried about
>>  is wrong.

I'm not sure what you're saying; it seems clear to me that either (a)
Ada-with-procedure-pointers allows my program, i.e. the program
successfully compiles, or (b) the program is rejected by the compiler.
(a) leads lets users write unsafe programs; (b) complicates the
semantics of Ada and places serious restrictions on what you can do
with procedure pointers.  It's as simple as that.

To be honest, my intention was not to prove that the addition of
procedure pointers to Ada would necessarily make Ada an unsafe
langauge -- instead, I just wanted to show that there are indeed
non-trivial problems in adding procedure pointers to Ada.  These
problems have not been sufficiently considered in the notes I've read
to date.

For instance, as you pointed out, activation records could be
allocated on the heap.  While this is very well possible, the
question then arises as to who reclaims that storage.  Whereas
the user normally has control over garbage collection (if his
or her compiler even provides garbage collection; most don't)
via "pragma CONTROLLED" and UNCHECKED_DEALLOCATION, this would
not be the case for activation records placed in the heap --
the user would have no way of referring to "activation-record"
objects.  It seems that, without further additions to the language,
compilers would be forced to automatically reclaim heap-allocated
activation records -- while this is again possible, this would
complicate compilers quite a bit.  And if compilers did indeed
provide automatic garbage collection of these activation records,
this would have serious consequences for real-time applications
which could not afford unexpected, momentary lapses due to
garbage collection.  Remember, Ada was designed with real-time
applications in mind -- imagine your fighter-plane refusing to
take evasive actions because it needed to garbage collect.

As you can see, the addition of procedure pointers to Ada opens up
quite a can of worms.

To consider another alternative, yes, you could restrict procedure
pointers from being returned into a broader scope than the one in
which they're defined.  Such restrictions detract from the worth of
procedure pointers in Ada, though, and they also complicate the
semantic processing that compilers must perform.  So you do pay
prices.

In any case, I agree that the problems which crop up when consider-
ing adding procedure pointers to Ada aren't insurmountable.  I still
doubt that these problems are really worth tackling in the first place.
Your use of procedure pointers to limit scope is hardly the only way
to do so without resorting to the use of "globals"...

Re: Orphaned Response

[kern]

I am interested in the LEX/YACC sources too.

Here are two little  lex  sources  I  wrote,  though  I  am  a
newcomer  to  unix.  The  first is to translate all characters
into upper  case  except  Ada  reserved  words,  comments  and
strings. (I forgot character literals.)
Known bugs: Character literals are translated,
	    first word of text sometimes treated erroneously

The second is to remove/add comment starters  "--"  to  lines.
(To enable i.e. adjustment procedures in comment blocks.)

					Horst
Mailing address: mcvax!unido!ztivax!siedap!kern

SEP  [ \n()*+-./:;<=>|&]
KEYW (abort|abs|access|all|and|array|at|begin|accept|body|case|constant|declare|delay|delta|digits|do|else|elsif|end|entry|exception|exit|for|function|generic|goto|if|in|is|limited|loop|mod|new|not|null|of|or|others|out|package|pragma|private|procedure|raise|raise|range|record|rem|renames|return|reverse|select|separate|subtype|task|terminate|then|type|use|when|while|with|xor)
%%
^{KEYW}/{SEP} ECHO;
{SEP}{KEYW}/{SEP} ECHO;
[a-z]  putchar (yytext [0] + 'A' - 'a');
--.*            |
\"[^"\n]*\"     |
[^a-z]          ECHO;

--------------------- 2nd crime---------------------
%START TAB
%%
^[ \t]*--   { int i;
	      for (i=0; i<yyleng-2; i++)
		  output (yytext[i]);
	     printf ("  ");
	    }
^[^ \t]         |
^" "[^ ]        |
^"  "[^ ]       {
		 printf ("-- ");
		 output (yytext[yyleng-1]);
		}
^\t+        {for ( ; yyleng>1; yyleng--)
		output ('\t');
	     BEGIN TAB;
	    }
<TAB>" "*   ECHO;
<TAB>[^ ]   {printf ("     -- ");
	     ECHO;
	     BEGIN 0;
	    }
^" "*       { int i;
	      for (i=0; i<yyleng-3; i++)
		     output (' ');
	      printf ("-- ");
	    }