Re: Two ideas for the next Ada standard

[dewar@cs.nyu.edu (Robert Dewar)]

Michael F Brenner <mfb@mbunix.mitre.org> wrote:

>In additions to these two ideas, we should consider two more:
>
>(1) Efficiencies required for systems programming:
>(1a) Permit placing a variable at an absolute physical machine
>address (as opposed to a gnat virtual address).

   This is not a language issue, what on earth is a physical or virtual
   address? At the language semantic level it is a nonsense concept!
   Address values are implementation dependent. On many systems the
   concept of a physical address is meaningless at the problem program
   level. On an implementation where it makes sense, it can be supported.

   On most systems you cannot just let a program specify a physical
   address, since you have to explicitly map the address. The normal
   approach would be to use an expressoin like map(physical-address)
   as the expression in the address clause.

>(1b) Correct the language design error that CHECKED conversion
>between signed and unsigned integers may overflow or raise constraint_error.

   I disagree that this is a design error, I have no idea of what probably
   implementation dependent semantics you have for the result, but it
   seems a bad idea to follow this idea.

>(1c) Add logical operations (AND, OR, etc.) on signed numbers.

   What for, the result is unpleasantly implementation dependent. If
   implementations want to allow this, fine (GNAT does), but I don't
   think it should be in the language.

      In GNAT:

         with Text_IO; use Text_IO;
         procedure q is
         
            function shift_right (a : integer; b : natural) return integer;
            pragma import (intrinsic, shift_right);
         
            x,y : integer;
         begin
            x := 24;
            y := shift_right (x,3);
            put_line (y'img);
         end;

>(1d) Make software reuse through generics efficient by REQUIRING
>all expressions that would have been static in a non-generic package
>to remain static when the package is made generic. In Ada-95,
>you lose staticness all over, and, consequently, you lose compile
>time computation of most expressions, when you make a package generic.

   I do not understand your point here, it seems confused. You do not lose
   any compile time computation of expressions in generics, and indeed
   compile time computatoin has little to do with staticness (you are
   confusing two separate concepts, one which has semantic significance
   and one which is purely an implementation issue).

>(1g) Legalize a compiler-independent way to overlay two variables.
>This could be accomplished without offending non-system-programming
>purists, who are rightfully concerned with the safety violation
>implied by overlaid variables in two steps as follows. First, mandate
>that unchecked_conversions generate no code, ...

   What does generate code mean? Nothing at all semantically. I think you
   are badly confusing the notion of language definition and implementation
   requirements. As a matter of fact, many unchecked conversions MUST
   generate code even when conversion between identical sized types
   is involved, or you get the wrong results. A typical example is
   that a biased value, unbiased in a register, must be rebiased for
   an unchecked conversion.

>(1h) A FAST, mandatory, standarized way to put a stream of bytes out to
>a file, with no intermediate packages or code between the
>Ada call and the underlying file system WRITE and READ commands,
>giving random access to standard_input and the same I/O speed as
>competing languages, which now requires compiler dependent code.

   This seems very curious to me. There are no consistent "underlying
   file system WRITE and READ commands" that are consistent across
   operating systems. If you mean that you want access to some particular
   set of routines (e.g. Unix fread and fwrite, which are of course not
   available on all systems), then call these routines.

   random access to standard input is a highly implementation dependent
   concept.

   how would you map your ideas here into the file system of the IBM
   mainframe, or the VMS record manager?

">(2) Make packages into second-class objects; currently they are
>third-class objects, forbidding arrays of packages and forbidding
>passing packages as generic parameters; a second-class package
>would permit passing non-generic packages as generic parameters, which
>permit an easy-to-read, easy-to-implement, very efficient method of
>creating iterators with a single level of generics across a wide
>set of data structures.

   That's a much harder feature to define than you think.