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'.
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.
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";
Yes, agreed on Ada.Interfaces and the FFI, it's one of the best. The only thing "missing" is auto-import of the definitions in C header files (but there be different dragons). gcc -fdump-ada-specs works fine, but it's effectively a duplication of (non-authoritative) information. That's fine if you're targeting one system, but when targeting multiple systems a single "with Interfaces.C.Syscall_H" quickly becomes a maze of alternative package bodies and accompanying conditional compilation logic.
> 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
I guess that goes to the core of the argument I was trying to make: not that Ada is bad, but that the low-level abstractions in Ada's stdlib are a case of premature optimization. Luckily, I take much less issue with the Numerics and Container parts of the standard library.
> To use the posix-flags, you use the Form parameter
Do you have any examples/documentation on the use of the Form parameter? According to the RM, it's a String argument so I wouldn't have expected it to support flags.
(Also, to correct myself on the signalfd issue: there is GNAT.Signals.Block_Signal to mask signals on the Interrupt_Manager thread)
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.
> 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;.)
(1) encapsulation, realized in Ada by private types.
(2) reuse, realized in Ada via generics. (3) inheritance, realized with type-cloning. (4) abstract interfaces, without touching OOP, arguably generics. (5) type extension, for extending types you finally have to buy into OOP. (6) dynamic dispatch.reply