Which doesn’t address the reason that I’ve seen for avoiding Ada:
There is one open source implementation and it is owned by an organisation that has already changed the license in an incompatible way once, picking one that was unacceptable even for internal use, to a number of companies.
Ironically, the existence of clang has helped a number of places stay with GCC for C/C++ because they have a second source if the FSF’s future licensing policy becomes unacceptable to them. There’s no equivalent for Ada.
AdaLabs was looking at doing an LLVM Ada front end in the past but didn’t make much progress. Until that exists, I wouldn’t recommend any company use Ada: even if taking a dependency on a GPLv3 toolchain with a GPLv3 + runtime exemption library is acceptable (which it isn’t for a lot of places), there’s no guarantee that a dependency on a GPLv4 toolchain with a GPLv4 + runtime exemption library is going to be.
That’s connecting the GNU front end to an LLVM back-end. The same thing worked with DragonEgg (which did GIMPLE to LLVM IR translation and so worked with GNAT and other GCC front ends). It doesn’t remove the dependency on the good graces of the FSF.
One thing about Ada I’d like explained better is dealing with safety of dynamically allocated memory. The usual answer I see is “you just avoid allocating memory” which is underwhelming. Everyone already avoids allocating memory, so this feels like dodging the question.
I must say, after I’ve learned some Ada I also became somewhat more skeptical about Ada’s safety even without memory allocation. Ada has uninitialized variables, data races and mutable aliasing-related type confusion out of the box — you actually need SPARK to guarantee even program integrity.
I don’t know how big of a deal that is in practice: intuitively, it still seems way way better that C’s collection of dangerously sharp objects.
Yes, it’s nowhere near as safe as the evangelists say. Its semantics are equivalent in power to any C-style language. Of course it’s better than C because it avoids a lot of undefined behavior and has less “features” designed to circumvent the type system, but semantically it is very weak. It’s no wonder that Ada is being replaced by C++ and not some other language with safer inherent semantics. The type of C++ static analysis tools people who use Ada use already dull C++’s sharp corners, and the difference in semantic power is minimal.
Ada definitely isn’t safe, but it’s harder to shoot myself in the foot than with C or C++.
mutable aliasing-related type confusion
Thanks, that’s an interesting example which still works on FSF GNAT 10.3! That’s a very atypical combination of infrequently used features (variant record, fields with vtables in a variant, defaulted discriminant, global state with a procedure operating on that state) to get there. I’m keeping that on hand to remind myself how I can be bitten by it. I don’t think that expression, M := should error at compile-time, discriminants are supposed to only be bound once, but only since it has a defaulted discriminant, the unassigned value M : Magic is allowed and also that assignment.
uninitialized variables
The compiler is usually pretty good about ensuring you initialize things if you forget, with a few exceptions, like mentioned above. The one time this bit me was in a defaulted aggregate, where I set all remaining fields in a record to their “default” values, and one didn’t have one: Var := (FieldA => ValueA, FieldB => ValueB, others => <> ). Supposedly pragma Normalize_Scalars is supposed to help with this.
data races
Ada’s protected objects help deal with data races in a pretty interesting way, which can include arbitrarily complex conditional guards on access, in addition to operating like a mutex. You have to make sure your data is set up that way though.
“you just avoid allocating memory”
Yeah, it seems really, really weird to hear people say that, and I was originally very skeptical about it. After a while of working in Ada, you realize it’s similar to C++ where you wrap you have containers and other resources usually wrapped in RAII (controlled) types and just forget about it. The few times I’ve needed allocations, I’ve used a RAII-based reference-counted pointer. The other reason you don’t deal with many allocations is that you can return variable-length arrays with their bounds on the stack, and implementations are required to check for stack overflow.
Ada is not memory safe in the presence of dynamic memory deallocation. There is no solution to this problem in Ada. Even the deallocation function is named Unchecked_Deallocation .
Which doesn’t address the reason that I’ve seen for avoiding Ada:
There is one open source implementation and it is owned by an organisation that has already changed the license in an incompatible way once, picking one that was unacceptable even for internal use, to a number of companies.
Ironically, the existence of clang has helped a number of places stay with GCC for C/C++ because they have a second source if the FSF’s future licensing policy becomes unacceptable to them. There’s no equivalent for Ada.
AdaLabs was looking at doing an LLVM Ada front end in the past but didn’t make much progress. Until that exists, I wouldn’t recommend any company use Ada: even if taking a dependency on a GPLv3 toolchain with a GPLv3 + runtime exemption library is acceptable (which it isn’t for a lot of places), there’s no guarantee that a dependency on a GPLv4 toolchain with a GPLv4 + runtime exemption library is going to be.
There’s an LLVM front end in progress. I haven’t tried it out yet, but it seems to be under active development.
That’s connecting the GNU front end to an LLVM back-end. The same thing worked with DragonEgg (which did GIMPLE to LLVM IR translation and so worked with GNAT and other GCC front ends). It doesn’t remove the dependency on the good graces of the FSF.
Ah, thanks, I see your point now, I hadn’t thought about that.
One thing about Ada I’d like explained better is dealing with safety of dynamically allocated memory. The usual answer I see is “you just avoid allocating memory” which is underwhelming. Everyone already avoids allocating memory, so this feels like dodging the question.
I must say, after I’ve learned some Ada I also became somewhat more skeptical about Ada’s safety even without memory allocation. Ada has uninitialized variables, data races and mutable aliasing-related type confusion out of the box — you actually need SPARK to guarantee even program integrity.
I don’t know how big of a deal that is in practice: intuitively, it still seems way way better that C’s collection of dangerously sharp objects.
Yes, it’s nowhere near as safe as the evangelists say. Its semantics are equivalent in power to any C-style language. Of course it’s better than C because it avoids a lot of undefined behavior and has less “features” designed to circumvent the type system, but semantically it is very weak. It’s no wonder that Ada is being replaced by C++ and not some other language with safer inherent semantics. The type of C++ static analysis tools people who use Ada use already dull C++’s sharp corners, and the difference in semantic power is minimal.
Ada definitely isn’t safe, but it’s harder to shoot myself in the foot than with C or C++.
Thanks, that’s an interesting example which still works on FSF GNAT 10.3! That’s a very atypical combination of infrequently used features (variant record, fields with vtables in a variant, defaulted discriminant, global state with a procedure operating on that state) to get there. I’m keeping that on hand to remind myself how I can be bitten by it. I don’t think that expression,
M :=should error at compile-time, discriminants are supposed to only be bound once, but only since it has a defaulted discriminant, the unassigned valueM : Magicis allowed and also that assignment.The compiler is usually pretty good about ensuring you initialize things if you forget, with a few exceptions, like mentioned above. The one time this bit me was in a defaulted aggregate, where I set all remaining fields in a record to their “default” values, and one didn’t have one:
Var := (FieldA => ValueA, FieldB => ValueB, others => <> ). Supposedlypragma Normalize_Scalarsis supposed to help with this.Ada’s protected objects help deal with data races in a pretty interesting way, which can include arbitrarily complex conditional guards on access, in addition to operating like a mutex. You have to make sure your data is set up that way though.
Yeah, it seems really, really weird to hear people say that, and I was originally very skeptical about it. After a while of working in Ada, you realize it’s similar to C++ where you wrap you have containers and other resources usually wrapped in RAII (controlled) types and just forget about it. The few times I’ve needed allocations, I’ve used a RAII-based reference-counted pointer. The other reason you don’t deal with many allocations is that you can return variable-length arrays with their bounds on the stack, and implementations are required to check for stack overflow.
Ada is not memory safe in the presence of dynamic memory deallocation. There is no solution to this problem in Ada. Even the deallocation function is named
Unchecked_Deallocation.