Re: Standard Ada program w\ all (possible) features

[geert@fozzie.sun3.iaf.nl (Geert Bosch)]

It was written:
Q: "Where can I get a sample program that includes as many as
    Ada features as possible?"
A> "Hopefully nowhere! What a horrible idea.

James Squire wrote:
  "Not if you are evaluating a compiler it isn't. "

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
  "No, I disagree, a test program that randomly used as many features as
   possible in a single program would be unlikely to be a useful test. What
   is needed is a much more systematic approach to testing interactions of
   features." 

The best test will be the real world. Of couse you need to check coverage,
but real-world use is much different from theoretical use.

I've written a basic OS/2 Presentation Manager framework using
delegation instead of specialization. This way parts can work together
with others than their parents, which makes it possible to build
applications withou  creating children.  The delegation is implemented
using a layered filter approach.

Many Ada'95 "features" (I hate the word) are being used and indeed the
Ada compiler (GNAT v3.05) cannot compile it, so it is a test of the compiler
too.

The framework uses:
  -- child units to allow extensions of the basic model to 
     look at private data
  -- generic packages, since delegation works for all types of messages 
  -- generic packages using generic packages as formal parameter, since
     the layered filter can use any Boolean_Set implementation
  -- tagged types, since specialization is still a useful concept for GUI
     frameworks.
  -- Complex C interfacing, since the OS/2 API is aimed at C.
  -- Access-to-subprogram values, since Presentation Manager needs callback
     functions
  -- Tasking, since every window has its own seperate thread (in OS/2 speak).
  -- Class-wide types, for polymorphism   

I can't really pick the things that are new to Ada-95, because many of
them are small but important details/enhancements
One strange thing was that I found that specialization and class-wide
types were also needed at a few points to break cyclic dependency.

Example:
   The Message_Filter package needs a Message type
   The Message type needs a Window
   The Window has a Message_Filter

Using an abstract message not containing the Window turned out to be a
solution. The Window converts any Window_Message to a Root_Message before
delegation which uses the Message_Filter. The subpart to which the
message is delegated converts it back to a Window_Message.

Little bit clumsy at first, but when you think about it, there are no
other solutions except using access types all over the place. Also, when
you consider that the contents of the message should be opaque to the
Message_Filter package using a Root_Message type is more logical.

So, when you want to test a compiler, implement a solution to a complex
problem. You also test the language that way. Probably we won't see a 
good Ada'95 compiler before people actually write (useful) Ada'95
programs and learn the (im)possibilities of the new language extensions. 
For example, I didn't see any tasking Ada-95 program larger than a few
hunderd lines yet.

Probably nobody will ever succeed in correctly implementing the
complete Ada'95 language (even excluding annexes). So checking
corners of the languages for bugs is not useful, concentrate on
real-world programs. Those are the programs an Ada compiler should
be able to compile.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl