Re: Ada2005 clear screen etc.

[sk <noname@myob.com>]

Hi,

Stephen.A.Leake@nasa.gov :
 > ... ANSI standard ...

I was more panicing over the thought that the language
be bound to some possibly transient fashion and hadn't
stopped to consider some never dying, ubiquitous things
like the ANSI terminal standard.

However, I tend towards the <Kilgallen@SpamCop.net> comment

 > Because the Ada standard should be for things that require
 > support from the compiler vendor.

and subsequent comments on the response cycle for a set of
libraries.

With that thought, how about an official but very flexible
and distinctly separate package hierarchy ?

(.. and I am sure it has been discussed before or there are
comments as part of the Ada200y process, sorry for lack of
opportunity to fully investigate. Also please note that I
am not familiar with any of the ongoing Ada library projects
or the "C++" standard library so, again, sorry if this is
a rehash of other discussions or duplication of ideas so
RTFM me, with URL, if appropriate).

Standard
     Ada.xxx
     Interfaces.xxx
     System.xxx

     Libraries.xxx

"Libraries" just a graft point, nothing significant about
the name. "Libraries" would, by agreement, have some invarient
subtrees. Perhaps two levels of abstract/conceptual packages
before specific solutions are grafted into the tree ?

Libraries.Vendor (invarient, children as needed)
     .Gnat.
         .Os_Lib;
     ...
     .RRSoftware
         .Claw
     ...

Libraries.Host (invariant, children as needed)
     .Linux
     .Windows
         .Win32Ada

Libraries.Host_Interfaces.
     .Console.
         .ANSI_Terminal
             <Perhaps the M.Feldman terminal package >
         .VT100_Terminal
         ...
     .Graphical
         .Win32Ada renames Libraries.Host.Windows.Win32Ada
         .GtkAda
         ...
     .File_System
         ...
     .Network
         .Transport
             .Sockets
             ...
         .Protocols
             .Smtp
             .Http
             ...
     .etc

Libraries.Objects_And_Methods
      .Containers
          . <The current Container library project perhaps>

      .Strings
          <Just "Ada.Strings.*" as an example of the purpose
           for "Libraries.Objects_And_Methods">

Libraries.Standardized_Interfaces
      .Posix
      .RFCs

etc

There are a lot of crossovers, but Ada has the "renames"
mechanism which could associate 
"Libraries.Vendor.Gnat.Directory_Operations" for example,
with "Libraries.Host_Interfaces.File_System.Directories"

This needs a lot more thought and work (rearrangment, better
nameing, interdependencies, circularity, management burden etc),
however, it could provide a more cohesive framework into which
APIs would fit without burdening the core language or its "Ada.*"
package hierarchy.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------