OneWingedShark

Consider using a metaobject system and having every object/type in your system able to use ASN.1 -- this will allow any language to hook into this system and you get OpenVMS-like interlanguage compatibility "for free". Add in a stream system and a general text <-> object system and you now have a system where every program is using a system-provided parser for command parameters.

Ada has some excellent GENERICs, you can use them to great effect for reducing code-size.

I'd recommend ASN.1 for almost everything that XML is used for. Unfortunately, is a [semi-] human-readable file is in your list of 'needs', then that is "mostly" ruled out.

(So, what you could do is use the XML-encoding of ASN.1, and then use _that_ in the place of your (current) XML, and then simply allow eg DER encoded objects.)

GNAT (not Ada) has an implementation restriction that you cannot have multiple compilation-units in a single file; I believe that the dot-replacement is a holdover from when GNAT/GCC was dealing with DOS.

Why is that? I find Ada much nicer than the C-languages when it comes to arrays: A'Range, A'Length, A'First, and A'Last are super-useful, as is the unconstrained array.

You can even use unconstrained arrays to provide the same functionality that Optional does in functional-programming, provided the element-type can be an element of an array:

    -- Here we define an index-type with one value.
    Subtype Boolean_Index is Boolean range True..True;
    -- And here we define an array indexed by it, but can also have length 0.
    Type Optional(Boolean_Index range <>) of Element;

And there you have the mechanism for Optional; just use "For Object of Optional_Array Loop" to enclose your operations and bam, it works perfectly.

Both are, IMO, inferior to Ada's TASK construct.

While Ada does have `Unchecked_Deallocation` and `Unchecked_Conversion`, Ada out-of-the-box provides safety roughly on-par with the high-integrity C++ style-guide. For provable safety, the SPARK subset/provers are used.

There's a lot you can do in Ada without resorting to them, and even with using them it can be perfectly fine, such as (eg) "view conversion" of a register or memory-mapped location -- remember that a lot of APIs (and ABIs) have been kneecapped by catering to C's inabilities, so even if the idea is directly expressible in some higher level language it will be exposed at the lower level.

An interesting read, though perhaps it would have benefitted from going the route that made things click. After all, each of the features can be independently achieved, so why not show that _before_ winding around to the "whole bag" of OOP?

(1) encapsulation, realized in Ada by private types.

    Package Geometry is
       Type Point is private;
       Function  Create( X, Y : Integer ) return Point;
       Function  X( Object : Point ) return Integer;
       Function  Y( Object : Point ) return Integer;
       Procedure X( Object : in out Point; Value : Integer );
       Procedure X( Object : in out Point; Value : Integer );
    Private
       Type Point is record
          Data_X, Data_Y : Real:= 0.0;
       end record;
    
       Function  X     ( Object : Point ) return Integer is (Object.Data_X);
       Function  Y     ( Object : Point ) return Integer is (Object.Data_X);
       Function  Create( X, Y : Integer ) return Point   is
         ( Data_X => X, Data_Y => Y);
    End Geometry;

(2) reuse, realized in Ada via generics.

    Generic
       Type Item is private;
       One : Item;
       with "*"(Left, Right : Item) return Item is <>;
    Function Generic_Exponent( Base : Item; Exponent : Natural ) return Item;
    -- ...implementation
    Function Generic_Exponent( Base : Item; Exponent : Natural ) return Item is
     (case Exponent is
        when 0 => One,
        when 1 => Base,
        when 2 => Base*Base,
        when others =>
          -- Rule: X**2k = (X**k)**2; X**2k+1 = (X**k)**2 * X.
          (Generic_Exponent(Base, Generic_Exponent(Base, Exponent/2), 2)
            *  (if Exponent mod 2 = 1 then Base else One);
     );

(3) inheritance, realized with type-cloning.

    Type Temperature is range -40..2_000;
    Type Probe_Range is new Temperature range -20..200;

(4) abstract interfaces, without touching OOP, arguably generics.

    (See above; note how we're depending on the type, a "one value", and a "multiply" operation.)

(5) type extension, for extending types you finally have to buy into OOP.

    Type Base is null record;
    Function Text(Object : Base) return String is ("[]");
    
    Type Color is ( Red, Green, Blue, Black, White );
    Type Colored_Thing is new Base with record
       Color_Data : Color := Red;
    end record;
    
    Function Text(Object : Colored_Thing) return String is
      ('[' & Color'Image(Object.Color_Data) & " ]");

(6) dynamic dispatch.

    -- Gets text from user.
    Function Prompt return String; -- def elsewhere.
    -- Gets a previously saved object.
    Function Get( Name : String ) return Base'Class; -- def elsewhere.
    Unknown_From_User : Base'Class renames Get( Prompt );
    --...
    -- The following will print "[]" if it is BASE, and
    -- "[ COLOR ]" when COLORED_THING, replacing 'COLOR' with
    -- the textual representation/literal for the value.
    Ada.Text_IO.Put_Line( Unknown_From_User.Text );

I read about a VHDL that used DIANA. DIANA was an IR in some Ada compilers; I would imagine that such a common IR would facilitate exactly those test benches with an ease that borders on 'ludicrous'.

Found the link: https://github.com/ada-game-framework

I'm pretty sure you can get the new crate-system to grab/make you a working build. https://alire.ada.dev/

Ok, so the Form parameter is implementation defined; this was to allow the implementations the 'wriggle room' to interface with the host-system.

For GNAT, these two pieces of documentation are instructive: https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat... https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_rm/FORM-String... (This second one is older documentation, but illustrates how platform-specific Form parameters could be used.)

    Ada.Text_IO.Create (
        File => File,
        Mode => Ada.Text_IO.Out_File,
        Name => "test.txt",
        Form => "shared=no"
      );

The "maze of alternative package bodies and accompanying conditional compilation logic" is an artifact of C's approach to 'portability' using the preprocessor. Typically, the conditionality should be stable once you abstract it (using the compiler's project-management to select the correct body for a particular configuration) -- As a stupidly trivial example, consider the path separator, for the specification you could have:

    Package Dependency is
       Package OS is
          Function Separator return String;
       End OS;
    End Dependency;
    -- ...
    Package Dependency is
       Package body OS is separate;
    End Dependency;

    -- Windows
    separate (Dependency)
    Package OS is
      Function Separator return String is ("\");
    End OS;

    -- Classic Mac
    separate (Dependency)
    Package OS is
      Function Separator return String is (":");
    End OS;

    -- VMS
    separate (Dependency)
    Package OS is
      Function Separator return String is (".");
    End OS;

    -- UNIX-like
    separate (Dependency)
    Package OS is
      Function Separator return String is ("/");
    End OS;

Then in your the rest of your program, you program against the abstraction of DEPENDENCY.OS (and whatever other dependencies you have, likewise), and thus separate out the implementation dependency.

It's actually really great for anything where you want to be more safe/correct, like banking... and the `TASK` construct makes it really nice for naturally multitasking situations. A couple of the people in the community are putting together gamedev tools/engine.

Hey, let me encourage you: do it. You might be surprised at the agreement you get, or at discussions.

Yep. And sometimes it's hype over the weirdest things... a good example "dependency injection".

    Generic
      Type Index   is (<>);                                      -- Any discrete type.
      Type Element is limited private;                           -- Any non-discriminated type.
      Type Vector  is array(index range <>) of element;          -- An array-type of Element, indexed by Index.
      with Function "="(Left, Right: Element) return Boolean <>; -- Equal, defaulted.
      with Function "<"(Left, Right: Element) return Boolean <>; -- Less-than, defaulted.
    Function Generic_Sort( X : Vector ) return Vector;

Now when we instantiate we can inject '>' in place of the '<', reversing the direction of the sort:

    Function Sort is new Generic_Sort( Index => Integer, Element => Integer, Vector => Integer_Array, "<" => ">");

To be fair, the file-handling is probably the 'crustiest' part of the standard library. (To use the posix-flags, you use the Form parameter.)

The best way to use Ada, IMO, is type-first: you define your problem-space in the type-system, then use that to solve your problem. -- Also, because Ada's foreign-function interface is dead easy, you could use imports to handle things in a manner more amiable to your needs/preferences, it's as simple as:

    Function Example (X : Interfaces.Unsigned_16) return Boolean
      with Import, Convention => COBOL, Link_Name => "xmpl16";

You can even put pre-/post-conditions on it.

Pretty much [close enough for government work]; see: https://stackoverflow.com/questions/7764656/who-is-diana-and...

> I suspect, though, that memory safety is one of the most important kinds of safety.

I don't. It seems to me like "memory-safety" is a response to the legacy of C and "C-compatibility) WRT poor behavior/respect of types; example: int/address punning, int/boolean punning, array/pointer punning, etc. (NUL-terminated stings could fit here, too as they're a consequence of C's address/array confusion.)

Contrary to this, would be correct typing. Consider SQL-injection and how the "best practice" is to never take data from the user... well we can take data from the user AND ensure there's no possibility of injection:

    Subtype Numeric is String
      with Dynamic_Predicate => (for all C of Numeric => C in '0'..'9'),
           Predicate_Falure  => raise Constraint_Error with "'" & Numeric &"' is not numeric.";
    --...
    Count : Numeric renames Get_User_Value;
    --...
    return Query("SELECT \* FROM Some_Table WHERE Count=" & Count & ";");

The above is perfectly safe because the constraint imposed prohibits the SQL-injection... and you can even enforce something like SQL_Escaping:

  PACKAGE Example IS
    -- The only way to get a value of ESCAPED_STRING is via calling Create.
    Type Escaped_String is private;
    Function Create( X:String ) return Escaped_String;
  PRIVATE
    Type Escaped_String is new String;
    Function Create( X:String ) return Escaped_String is
    ( SQL_Escape(X) );
  END Example;

> The tool would have to be pretty damn good. And also not introduce business risk or at the very least a minimal business risk.

That is actually quite possible. Ada is in a really good place as far as that goes: imagine the cost of writing an IDE (to include compiler) for, say, Ada, PL/SQL, and VHDL -- given the common lineage, you could make a custom internal representations (IR), where each language has a 'Subtype' constraint for its particularity (e.g. `Subtype Ada_IR is General_IR with Dynamic_Predicate => Is_Common(Ada_IR) or Is_Ada(Ada_IR);`, and so on for PL/SQL and VHDL), make these IRs with SPARK proving, as you implement PL/SQL and its query-engine also implement SPARK's proof-tools and SMT-interfaces, proving it as you go, next implement and prove code-gen/HW-synth.

Now, put the IDE source through the IDE, and BAM! Now you have a proved IDE+compiler for Ada, PL/SQL, and VHDL giving you a very solid platform. (Also, as you would have a DB-engine onboard, you could populate the IDE with templates and run a query like: SELECT Name, Code FROM Entities WHERE Purpose LIKE “%SCSI%”;... or SELECT Name, Purpose FROM Algorithms WHERE Purpose LIKE “%SORT%” AND Ω <= log_2;.)

Also, being Ada-based, you could use Ada's Distributed Systems Annex to distribute portions of the IDE, and/or implement CI/CD as per https://users.ece.utexas.edu/~perry/work/papers/icsm87.pdf

Memory management in Ada is such that you need pointers (and the heap) far, far less than in other languages: the language allows the return of values to objects of unconstrained subtypes to provide the constraints; example:

    Text : Constant String := Read_Chapter( Book );

Additionally, nesting DECLARE blocks and subprograms allows a fairly fine-tuned memory-usage/cleanup using the stack. The above example could, for example, be part of an outer DECLARE block, which has an inner DECLARE, perhaps with "Paragraphs : Constant String_Vector := Get_Paragraphs( Text );" in its declarative region and "For Paragraph of Paragraphs loop" in its body... as soon as the block is exited, the stack is popped, reclaiming the used memory. This, in turn, means that the need for heap allocation is greatly reduced.

Here's an excellent presentation on Ada's memory management: https://archive.fosdem.org/2016/schedule/event/ada_memory/

Honestly, Ada fits a LOT of that bill.

The type-system and forced spec/implementation split both work well to catch errors; you can go further with SPARK [proving] and using Pre- and Post-conditions, type-invariants.

If you want that same GUI/RAD style, Delphi is still around.

The items "A serious take on a contract-based language" & "A language with semantic relations" are covered pretty nicely by Ada's SPARK subset/tools... and the really great thing is that the "aspects" are part of the code and don't "go stale" like annotated comments do.

Look at Ada and its error-messages.

>>say arrays that "know their own length"

>

> There's a fair amount of C code that does just that and does it for a long time.

No, there isn't.

There can't be because of how arrays in C degenerate into pointers/addresses; see Walter Bright's "C's Biggest Mistake" -- here: https://www.digitalmars.com/articles/C-biggest-mistake.html

>> or numeric-types that are range-constrained.

> Those don't need astral and can be passed through C ABI just fine.

No, they can't.

If you're passing a "Positive" through C's ABI you lose the fact that the value can be neither negative, nor zero. (Unless you mean "passed through" as in, "not mangled", but this is setting the bar so low as to be laughable.)

> The C language also has a stable ABI, which is basically the ffi for most languages,

C is honestly terrible to target/use as FFI, doing so precludes doing things correctly, or more advanced things like... say arrays that "know their own length" or numeric-types that are range-constrained.

Look into "SeedForth".

You are right; it's because the "modern" CI/CD is ill-designed, thanks in part to being "generalized" to handle text and "generalized" tools like C compilers and makefiles... instead of, you know, working in the actual problem-space.

See this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26....

> Isn't this why we have CI/CD and scheduled pipelines?

I mean, kind-of. One of the problems with CI/CD though is that they're poorly designed for the job they do; see this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26....

The TL;DR here is that by structuring your code and storing it in a database structured hierarchically you can solve CI/CD in a MUCH nicer manner: your root node's history becoming a history of the project in a compilable state.

> I imagine COBOL is similarly stable but I have no experience there.

I haven't programmed in COBOL, but it is quite stable. One of the really nice things in COBOL is the "Environment Division", which has a Configuration Section, which provides information about the system on which the program is written and executed. It consists of two paragraphs − – Source computer: System used to compile the program. – Object computer: System used to execute the program.

Another remarkably stable language is Ada, I have used it to compile non-trivial programs from 30+ years ago, on a different architecture than it was originally written for (granted, without system dependency) using a modern compiler without anything more than (1) renaming identifiers which had been made keywords, (2) splitting files due to GNAT's implementation limitation regarding compilation-units.