HAC (HAC Ada Compiler) is a quick, small, open-source Ada
compiler, covering a subset of the Ada language.
HAC is itself fully programmed in Ada.

Web site: http://hacadacompiler.sf.net/
From there, links to sources and an executable for Windows.

Source repositories:
  #1 svn: https://sf.net/p/hacadacompiler/code/HEAD/tree/trunk/
  #2 git: https://github.com/zertovitch/hac

* Main improvements since v.0.0996:

  - packages and subpackages are now supported
  - modularity: packages and subprograms can be standalone
      library units, stored in individual files with
      GNAT's naming convention, and accessed from other units
      via the WITH clause
  - validity checks were added for a better detection of
      uninitialized variables.

Package examples and modularity tests have been added.
Particularly, a new PDF producer package with a few demos
is located in the ./exm/pdf directory.

Enjoy!

Gautier
__
PS: for Windows, there is an integrated editor that embeds HAC:
LEA: http://l-e-a.sf.net
PPS: HAC will be shown at the Ada-Europe conference (presentation + tutorial)
http://www.ada-europe.org/conference2022/

I have a Gnat/Gprbuild project with several build configurations. I have a main source file and an secondary ads file which the main source file includes:

with Secondary_File; use Secondary_File;

The problem is that in each configuration, the secondary file has a different name. For example, it may be called Secondary_File_1.ads for one config and Secondary_File_2.ads for another. This makes it impossible to use the above with statement.

In C, I would do something like this:

#ifdef BUILD_CFG_1
#include "secondary_file_1.h"
#else
#include "secondary_file_2.h"
#endif

Is there a clever way to do something like this in ADA, using the Gprbuild system?

In order to illustrate a feature, what is better than a visual example?
In our case, the feature is the modularity, recently implemented in HAC (the HAC Ada Compiler).
So, a nice exercise was to try with a "real" visual package, PDF_Out (project Ada PDF Writer, link here).
Of course, HAC is still a small compiler project which doesn't cover all the sexy features of Ada - even those of the first version of Ada, Ada 1983, which already had extensive generics, aggregates (on-the-fly composite objects as expressions), default values in records or in subprogram parameters, exceptions or user-defined operators.
The easy way of down-stripping PDF_Out for HAC was to open the source code in the LEA editor (link here), and do frenetically and iteratively:

loop
  punch the compile key (F4)
  exit when the package compiles!
  make the code HAC-compatible (sometimes, it hurts!)
end loop

A few things that needed a downgrade for the HAC 0.1 language subset were:

• Object-oriented type extension (tagged type for PDF stream). In the simplified version, PDF files are the only supported PDF streams.
• Object.method notation
• Default values in records, replaced by explicit initialization.
• Inclusion of raster images (NB: the removal of that feature was unnecessary).
• User-defined exceptions (PDF_stream_not_created, ...).
• User-defined operators ("+", ...).
• Indefinite page table and offset table.

The result can be seen here:

Click to enlarge

You can experiment it yourself by checking out or cloning the latest version of HAC:

#1 svn: https://sf.net/p/hacadacompiler/code/HEAD/tree/trunk/
#2 git: https://github.com/zertovitch/hac

The new PDF examples are located in the subdirectory ./exm/pdf

I was working on some multithreaded Ada network code, which involved accepting and handling multiple connections in parallel. An ideal situation for the use of Ada tasks, no? Specifically, multiple task type variables, started in a loop.

Well, I did something like this:

with Ada.Text_IO;
use Ada.Text_IO;

Procedure foo is
   task type handler is
      entry Start(I: Integer);
   end handler;
   
   task body handler is
      task_index: Integer;
   begin
      accept Start(I: Integer) do
         task_index:=I;
      end Start;
      for I in 1..5 loop
         Put_Line("Task "&task_index'Image&": "&I'Image);
      end loop;
   end handler;

begin -- foo

   for t in 1..5 loop
      declare
         bar: handler;
      begin
         bar.Start(t);
      end;
   end loop;
end foo;

Expecting that the tasks, once they accepted the start entry, would execute in parallel. However, as in this example, the main task waited for each task to finish executing in turn:

$ gnat make foo
$ ./foo
Task  1:  1
Task  1:  2
Task  1:  3
Task  1:  4
Task  1:  5
Task  2:  1
Task  2:  2
Task  2:  3
Task  2:  4
Task  2:  5
Task  3:  1
Task  3:  2
Task  3:  3
Task  3:  4
Task  3:  5
Task  4:  1
Task  4:  2
Task  4:  3
Task  4:  4
Task  4:  5
Task  5:  1
Task  5:  2
Task  5:  3
Task  5:  4
Task  5:  5

Declaring all the tasks up-front, in an array fixed the issue, but left me curious about how this is actually working, why, and where this would be documented.

ARM2012 section 9.2 paragraph 6/3 seems to me to say that the main thread waits at the end of execution for it's child tasks to finish, but in practice it seems to be waiting when the tasks leave the current scope before continuing execution (i.e. looping around, and starting the next task).

Is this a compiler issue, a documentation issue, or a coding issue?