gjs@faust.UUCP (07/27/85)
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 --stt@ada-uts.UUCP (01/20/86)
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
stt@ada-uts (03/18/86)
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.
RCONN@SIMTEL20.ARPA (Rick Conn) (03/23/86)
Re the following message, see PD:<ADA.MATH>BIT.ADA in the
Ada Repository on SIMTEL20. This is a bit manipulation package
that is fairly transportable.
Rick
---------------
Return-Path: <@USC-ISIF.ARPA:info-ada-request@usc-isif.arpa>
Received: from USC-ISIF.ARPA by SIMTEL20.ARPA with TCP; Sat 22 Mar 86 21:50:17-MST
Received: FROM berkeley BY USC-ISIF.ARPA WITH TCP ; 22 Mar 86 20:00:44 PST
Received: by ucbvax.berkeley.edu (5.45/1.11)
id AA08274; Sat, 22 Mar 86 19:11:59 PST
Date: 18 Mar 86 16:55:00 GMT
From: decvax!ima!inmet!ada-uts!stt@ucbvax.berkeley.edu
Subject: Re: Orphaned Response
Message-Id: <4700020@ada-uts>
References: <306@telesoft.UKE>
Sender: usenet@ucbvax.berkeley.edu
Errors-To: <info-ada-request@usc-isif.arpa>
To: info-ada@usc-isif.arpa
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.
-------8606040723.576@ucbvax.Berke (GOODENOUGH@) (06/02/86)
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. -------
8606040749.950@ucbvax.Berke (GOODENOUGH@) (06/02/86)
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. -------
richw@ada-uts (08/07/86)
>> 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"...
kern@siedap.UUCP (08/08/86)
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 ("-- ");
}