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 --

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.

AND, OR & XOR on integers

[Erland Sommarskog]

In article <4700020@ada-uts> stt@ada-uts.UUCP writes:
>
>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.

NO, NO, NO! The author of this doesn't seem very knowledgeable in Ada. What
you do if you need logical operators on integers is of course:

FUNCTION "XOR"( IN Number : integer) RETURN boolean_value;

And to implement this functions is not very hard, unless you don't want
go as fast as an assembler instruction.

Erland Sommarskog

Re: AND, OR & XOR on integers

[stt]

function "XOR"(Left, Right : in Integer) return Integer;

  would be a better start :-)

Also, if you figure out how to implement this portably
in Ada, without using unchecked conversion, lemme know!

-S. Tucker Taft
 Technical Director of Ada compiler development ;-)
 Intermetrics, Inc.
 733 Concord Ave
 Cambridge, MA  02138

Re: AND, OR & XOR on integers

[David desJardins]

In article <4700025@ada-uts> stt@ada-uts writes:
>
>function "XOR"(Left, Right : in Integer) return Integer;
>
>  would be a better start :-)
>
>Also, if you figure out how to implement this portably
>in Ada, without using unchecked conversion, lemme know!

   Easy.  Just use repeated division by two to extract the bits, and
multiplication by two to construct the result.

   -- David desJardins

Re: AND, OR & XOR on integers

[Dik T. Winter]

In article <13158@ucbvax.BERKELEY.EDU> desj@brahms.UUCP (David desJardins) writes:
>In article <4700025@ada-uts> stt@ada-uts writes:
>>
>>function "XOR"(Left, Right : in Integer) return Integer;
>>
>>  would be a better start :-)
>>
>>Also, if you figure out how to implement this portably
>>in Ada, without using unchecked conversion, lemme know!

Portable *with* unchecked conversion?  How?  Conversion to what?
>
>   Easy.  Just use repeated division by two to extract the bits, and
>multiplication by two to construct the result.
>
Balderdash.  What is "(-1) and (1)"?  Yes, 0 on 2's complement machines,
1 on 1's complement machines.  So is there a portable way to decide whether
a machine is 2's or 1's complement?  We might enquire whether
INTEGER'FIRST = - INTEGER'LAST
but although from falsehood of this statement you might safely conclude
that the machine is 2's complement, the reverse is certainly not true
(a 2's complement might reserve the most negative number for special
purposes).  Another thing though, what should the system do if the
value returned is out of range (most negative number on a machine that
reserves it)?  Raise NUMERIC_ERROR?  You wouldn't want that.

Moral: you do not want logical operators on integers but logical operators
on packed array's of booleans.  The first part is required by the language,
the second part is left to the discretion of the implementors.
So: push the implementors to let pack work.
(I ignored decimal machines in this article; but implementing Ada on
such a machines will be fruitless.)
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo,decvax,philabs,okstate,garfield}!mcvax!dik
  or: dik@mcvax.uucp
ARPA: dik%mcvax.uucp@seismo.css.gov

Re: AND, OR & XOR on integers

[Dik T. Winter]

In article <290@zuring.UUCP> dik@zuring.UUCP (Dik T. Winter) (I) write:
>Balderdash.  What is "(-1) and (1)"?  Yes, 0 on 2's complement machines,
>1 on 1's complement machines.

To paraphrase myself: Balderdash.  It is the other way 'round of course.
Just got carried away by all those 0's and 1's.  (Never post news at night.)
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo,decvax,philabs,okstate,garfield}!mcvax!dik
  or: dik@mcvax.uucp
ARPA: dik%mcvax.uucp@seismo.css.gov

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 ("-- ");
	    }