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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b307bd75c8071241
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: newbie Q: storage management
Date: 1997/05/07
Message-ID: <dewar.863030172@merv>
X-Deja-AN: 240084785
References: <5k5hif$7r5@bcrkh13.bnr.ca> <336A065B.41C6@magellan.bgm.link.com>
 <dewar.862662935@merv> <336E15A4.167E@magellan.bgm.link.com>
 <5knhge$mul@top.mitre.org>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-05-07T00:00:00+00:00
List-Id: <comp.lang.ada>


Michael says:

<<Such a group surely exists (or existed) because they voted on Ada-95.
  However, that group does not necessarily represent all of the opinions
  in the Ada community. In particular, that group opposes the majority
  of the community in the topics of code efficiency, first class objects,
  and the horribleness of the text_io restrictions. In addition, that
  group opposes the minority of the community in other topics such as
  efficient conversions between unsigned and signed types, efficiency of
  doing unchecked_conversion without any object code generation, type
  conversions with no code generation, restrictions preventing certain
  time and space optimizations, and whether code efficiency should
  be discussed at all.>>

Well what Michael means here is that the group does not agree with him,
on some things, and that is especially interesting in view of the fact
that I never saw any contributions from him on the comment list (perhaps
he does not even know about it :-) But Michael is way off in thinking
that somehow this was a narrow process -- Michael do a little more
research on how the process worked and continues to work before you
make such statements -- as I say, you seem, somewhat surprisingly,
unaware of the comments operation! Hundreds of Ada users and experts
around the world participated actively in the design effort, which
was extraordinary open. And what was remarkable is that the ISO
standards group basically agreed on all decisions.

So, as I have said before, if you think that the group "opposes the
majority of the community in the topics of .... [put anything you
like here], you are talking nonsense. Please do not confuse the
opinions of a small number of enthusiasts on CLA with the majority
opinion of the Ada community (most serious Ada programmers I know
do not even bother to read CLA, they have better things to do with
their time, like writing Ada programs :-)

As for the group opposing things like efficient conversions etc, there you
have huge misunderstandings, common among those who have not been involved
in language design.

let's just take one of your examples "unchecked conversion without
any object code generation". It is completely impossible to discuss
this in a language standard. That is because no formal meaning can
be given to "object code generation".

Furthermore, it is technical nonsense. Of *course* you have to generate
code for unchecked conversion in some cases. For example, consider:

   type x is array (1 .. 3) of Boolean;
   for x'size use 3;

   type m is mod 2 ** 3;

   function f is new unchecked_conversion (x, m);

   v1 : x;
   v2 : m;

   v2 := f (v2);

On a big-endian machine you will VERY likely find a shift generated, since
it is natural to store x in the left 3 bits of a word or byte, and x in
the right 3 bits. If we took literally your demand of no code generation
then f would always yield a result of all zero bits -- not exactly what
the programmer intended. Similarly unchecked conversion may very well
involve sign or zero extension, and to insist otherwise might badly
damage the efficiency of code.

Code efficiency is of course discussed all the time in a language design
(an example is the very delicate discussions of the boudaries between
bounded errors and erroneous execution, for example

     x := a * b;

should the multiplication be bounded to at worst cause a program error
or store a wrong value? On most machines, an answer of yes is harmless,
but on some machines, the cheapest way to do the multiplication if b has
a small range is a jump table, and an undefended jump table could cause
a wild jump.

I realize that it is frustrating to practioners looking at things in 
simplistic terms that the Ada RM does no somehow guarantee that conforming
compilers are efficient, but it is simply not possible to achieve this.
Everyone wants efficient compilers, but it has to be the market place
that achieves this. Formal conformance measures are useless for addressing
this issue.

Sure we could have added some implementation advice in chapter 1

Advice. All Ada compilers should attempt to be as efficient as possible.

But even by the standards of some of the most meaningless statements in
the RM, this would hit a new low of uselessness, and achieve nothing.

<<We all appreciate the work that group has done in continuing the language.
  However, the decisions of that group were not perfect. Those decisions
  would have been better had some people with the opposing views been
  consulted. For example, Java would not have been necessary had Ada-95
  adapted packages as first class objects (permitting arrays of packages).
  Even as second class objects, permitting passing packages to generics,
  Java would have petered out in favor of Ada-95.>>

Of *course* people with opposing views were consulted. In fact there was
a big effort to consult anuyone willing to spend time, and Intermetrics
did a great job of organizing and disseminating the literally thousands
of messages they received commenting on the design.

As for the idea that putting package types in would have made Java
unnecessary, that's one of the more peculiar technical claims I have
seen on CLA. First of all, Java is not about being necessary, Java
is about all sorts of commercial considerations (not least of which
is for Sun to figure out how to compete with Microsoft). 

Even if you do take the naive view that languages appear and disappear
and prosper and fail solely based on their technical merits, your
proposition makes no sense. One of the main points about Java is that
it is a reaction to C++ being too large and too complex. The idea that
Ada could compete effectively and somehow have prevented Java from
appearing by making itself even larger and even more complex is truly
peculiar. 

Furthermore, I don't even see what you are getting at here. Ada effectively
spans the functionality of Java, especially if you include Annex E
semantics without any fancy additions.

As you should know, the issue of package types is an old one in the Ada
community. The Intel compiler actually implemented package types (but
was in other respects non-conforming, and was never validated, so it
was not an existence proof that it was possible to make this extension
cleanly). As I have mentioned before there was essentially one champion
for this idea (Tony Luckham), and true, he felt as you did that it was
a critical issue, but he was unable to convince anyone.

Now if you think you are right, and cannot convince anyone, there are two
ways you can react.

  (a) I am right, everyone else is wrong
  (b) I guess the idea must be wrong, or at least I don't know how to
        present it, so if I don't understand it well enough to convnice
        others, I must have some misunderstandings myself -- back to the
        drawing board.

I always prefer (b) here, and indeed there are decisions where I argued
strongly but was in a very small minority, and so abandoned the effort
on exactly grouns (b). My examples of this are:

    o  requiring GC, whatever that means, in the IS annex
    o  allowing double underscores in identifiers
    o  allowing in out parameters for subprograms

Some of you on the list will react to one or more of these points by saying
"RIGHT ON, HOW COULD THOSE IDIOTS NOT AGREE WITH YOU", but the fact of the
matter is that all three of these issues was extensively discussed by
people who know what they are talking about, and the decisions came down
decisevly on the other side, so I accept them as the clear collective
wisdom of a very wide community.

Little side note:

<<Even as second class objects, permitting passing packages to generics,
  Java would have petered out in favor of Ada-95.>>

Since any packages can be made generic, and obviousy packages to be
passed to generics must share the same signature, I do not see why
generic formal packages do not meet this requirement. Perhaps you
have not really studied this feature in detail -- it seems very
lightly used, considering its power -- it really brings the whole
notion of signatures to the Ada world.

<<Another reason to open up the group to more people is that this group feels
  that certain problems have been solved, according to recent posts. However,
  some people in the community do not have access to the reasons why they
  think they have been solved. In recent posts, I have been told that there
  are machine- and compiler-independent ways within Ada-95 to
   - put bits into a byte
   - do stream_IO
   - select alternate bodies for packages
     (for example, 1000 device drivers with the same visible part,
     of which one is selected as part of a computer program)>>

Yes, all these problems are solvable, but you can't expect people to 
neccessarily take the effort to educate you on how to solve these
problems. No one owes you that! I actually find these three examples
rather thin, I would expect any professional knowledgable Ada programmer
to be able to achieve these three goals, and certainly if you took a
commercial Ada course, such as those offered by Aonix, Ada Core Technologies,
and many others, you would learn how.

  Very briefly: putting bits into a byte is easily accomplished using rep
  clauses. The RM should be clear, if not you need to seek tutoring at a
  simpler level, e.g. from text books.

  Stream_IO is a fundamental feature of Ada 95, I don't understand what
  might be unclear here.

  The selection of alternative bodies is certainly outside the language
  proper, which only specifies the semantics of a program once assembled.

But within any implementation, there are easy solutions to this. In GNAT
you could use separate directories or the Source_File_Name pragma to
achieve this effect, or you could use GLADE (Annex E), and select the
partition structure to reflect the bodies that you want.

I do see a bit of a conflict here. There is a big gap between a self help
group which tries to teach one another simple things like this, and a
group that is knowledgable enough to usefully discuss language design 
issues. 

When new people first look at Ada, and start to learn it a bit at a time,
they naturally tread over well worn paths, but if you want to seriously
contribute to language design, you need to do some significant homework,
and realize that informal chats on CLA very rarely do more than touch
the surface of problems. Some of the materials to study are

   The old and new Rationale
   The old and new AI's
   The Implementor's guide for Ada 83
   Various Language Study Notes
   Geoff Mendall's books on Ada 83
   Norman Cohen's old and new books on Ada
   The original requirements documents
   The Ada 9X requirements document
   The Ada 9X mapping documents (all of them -- there are several,
     representing enlightening information on the progress of the design)
   The Ada 9X User requirements document
   The formal resolutions of WG9
   etc.

Yes, a lot of material, but there is a LOT of background you need here to
have the right perspective to understand how your suggestions fit into the
big picture (not to mention into the requirements of the majority of the
community)..

P.S. There was for a while a language study group associated with SIG Ada,
whose purpose was to provide additional input to the language design
process. It never was very successful in that goal, partly because a lot
of the people involved did not have the kind of depth of knowledge
necessarily to put together coherent proposals, but on the other hand,
I think a lot of people found it instructive and interesting. As I said,
in that kind of context, a lot of people spend a lot of time treading
over well worn paths and not discovering anything new, but on the other
hand discovering things for yourself is an excellent way of learning,
even if you find you are not thinking original thoughts after all :-)

Robert