Plan for next version of International Ada Standard

It was a quick example showing the tagged hierarchy, not the exact details.

Not sure what you mean.

I highly recommend you investigate the “visitor” pattern. When combined with an OO-based tree representation, it allows you to add new operations incrementally, to augment the “native” O-O capability of adding new tree variants incrementally. See, for example, Visitor pattern - Wikipedia

If you want to see a pretty complete, modern compiler front end written in Ada, using Ada OO and the visitor pattern (not precisely the standard version, but pretty close), see the ParaSail compiler/interpreter front end at:

The O-O-based tree structure is defined in psc-trees.ads and psc-trees-*.ads. One of the several parsers that build trees can be found in ../parser/parasail.y The visitor-pattern-based tree walking is all in psc-trees-semantics-static.ad? (first and second static-semantics passes) and psc-trees-semantics-dynamic.ad? (first and second dynamic-semantcs passes).

Feel free to create “issues” in the parasail github repository if you have questions or suggestions (GitHub · Where software is built).

2 Likes

Thanks! That’s what I was looking into currently to solve my problem. One of the tutorials mentioned it, but I’ve just started peeking at it, so it is good to know compilers out there implement that method. I’ll dig further into it.

Visitors are the basis of LLVM and Clang.

Visitor is probably one of the most common patterns in OO. BTW, Ada standard library prefers rather functional style to OO. E.g.

   procedure Iterate
     (Container : in Tree;
      Process   : not null access procedure (Position : in Cursor))

I tend to provide a visitor in cases like trees, where iteration is not a simple loop. E.g. B-tree

   type Abstract_Visitor is abstract
      new Ada.Finalization.Limited_Controlled with null record;
   function Visit_Item
            (  Iterator  : access Abstract_Visitor;
               Container : B_Tree'Class;
               Key       : Key_Type;
               Item      : Item_Ptr
            )  return Boolean is abstract;
   type Bucket_Traversal is (Quit, Step_Over, Step_In);
   function Visit_Range
            (  Iterator  : access Abstract_Visitor;
               Container : B_Tree'Class;
               Item      : Item_Ptr
            )  return Bucket_Traversal is abstract;
--
-- Traverse -- Non-generic tree traversal
--
--    Container - The tree to traverse
--    Iterator  - The iterator object to use
--    From      - The item to start at
--    To        - The key to stop at
--
-- This procedure traverses  items of the tree starting at the item From
-- less than or equal to To using the Iterator object.
--
   procedure Traverse
             (  Container : B_Tree;
                Iterator  : in out Abstract_Visitor'Class;
                From      : Item_Ptr;
                To        : Key_Type
             );

Visitor is more verbose on the client side, because you need to derive from the visitor base type. But there are advantages too as you can pack data into the visitor object rather than declare them in the scope of the visiting callbacks. So you are not bound a definite scope and can reuse visitor implementation in different places and use things out of the scope. I.e. visitor has a higher decoupling grade.

I never use when => others except during initialisation. I actually consider “the lack of case statements as harmful” following advice from a code reviewer that said he had seen too many bugs with tagged types that variabt records would have caught. I currently see the argument of case statements considered as harmful as optimising for writing and reducing maintainability and not increasing it. I want the compiler to inform me of all the places that need reviewing upon changes that affect case statements. I have noticed a couple of places like the style guide encourage using tagged instead of variants without any justification in it’s rationale. Atleast the new size limit might remove the access type issue which was one of my negative points for tagged types in my comparison which heavily favoured variant records for stemming the need for overrides to hardware register access. Another benefit of variant records was that they are so much simpler to understand.

1 Like

No bed stories, please. :unamused:

Need a rationale? :grinning:

Sure. Like this

typedef struct tagVARIANT {
  union {
    struct {
      VARTYPE vt;
      WORD    wReserved1;
      WORD    wReserved2;
      WORD    wReserved3;
      union {
        LONGLONG     llVal;
        LONG         lVal;
        BYTE         bVal;
        SHORT        iVal;
        FLOAT        fltVal;
        DOUBLE       dblVal;
        VARIANT_BOOL boolVal;
        VARIANT_BOOL __OBSOLETE__VARIANT_BOOL;
        SCODE        scode;
        CY           cyVal;
        DATE         date;
        BSTR         bstrVal;
        IUnknown     *punkVal;
        IDispatch    *pdispVal;
        SAFEARRAY    *parray;
        BYTE         *pbVal;
        SHORT        *piVal;
        LONG         *plVal;
        LONGLONG     *pllVal;
        FLOAT        *pfltVal;
        DOUBLE       *pdblVal;
        VARIANT_BOOL *pboolVal;
        VARIANT_BOOL *__OBSOLETE__VARIANT_PBOOL;
        SCODE        *pscode;
        CY           *pcyVal;
        DATE         *pdate;
        BSTR         *pbstrVal;
        IUnknown     **ppunkVal;
        IDispatch    **ppdispVal;
        SAFEARRAY    **pparray;
        VARIANT      *pvarVal;
        PVOID        byref;
        CHAR         cVal;
        USHORT       uiVal;
        ULONG        ulVal;
        ULONGLONG    ullVal;
        INT          intVal;
        UINT         uintVal;
        DECIMAL      *pdecVal;
        CHAR         *pcVal;
        USHORT       *puiVal;
        ULONG        *pulVal;
        ULONGLONG    *pullVal;
        INT          *pintVal;
        UINT         *puintVal;
        struct {
          PVOID       pvRecord;
          IRecordInfo *pRecInfo;
        } __VARIANT_NAME_4;
      } __VARIANT_NAME_3;
    } __VARIANT_NAME_2;
    DECIMAL decVal;
  } __VARIANT_NAME_1;
} VARIANT;

what a breath of fresh air!

The various suggestions for higher priority areas for enhancement of Ada were boiled down to a work plan approved by ISO WG9, the working group responsible for maintaining the International Ada Standard:

Instructions to the Ada Rapporteur Group (ARG) from SC22/WG9: Preparation of Revisions to ISO/IEC 8652:2023

The ARG GitHub Issue website will be the main place where possible specific enhancements will be brainstormed. Smaller working groups may then be convened to make more concrete proposals in specific areas, leading ultimately to a more formal “AI” (Ada Interpretation) which will be considered by the ARG.

9 Likes