Such a shame there is no macOS support for the new '2021 Community Edition', for either x64 or the newer Apple silicon (M1). As ARM is supported for other platforms (even as a cross compiler only) - not sure why the whole Apple community is being missed out in this update, for both x64 and ARM. Guess AdaCore customers don't use Apple products any more, so hence no availability for the Community Edition either..? One of the benefits of using Ada was the great cross platform support for Linux, Window, and previously macOS.
I'm half-obsessed with C interoperability in a variety of languages. I know Ada (or GNAT) has a C FFI, and I've done a little investigation/experimentation but not much.
Here are a few questions, which probably don't have an answer in the Ada standard but might in specific implementations:
* Is there a way to declare data layouts to have compatibility with C, similar to #[repr(C)] in rust?
* Is there a way to catch C++ exceptions?
* Is there a way to catch C longjmps()?
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
By default, the GNAT runtime uses setjmp/longjmp to implement exceptions. I'm not sure how you'd connect that to a C library's setjmp though.
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
ABIs are selected with the Convention aspect. Conventions are implementation defined and would require patches to the compiler to add new ones. GNAT currently supports Assembler, C, CPP, COBOL, and Fortran calling conventions.
"Conventions are implementation defined and would require patches to the compiler to add new ones."
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
If it could handle a longjmp() as well, then the new Convention would also do whatever setup (manipulate some global variables and call setjmp()) so that the caller doesn't have to worry about the longjmp().
The challenge with handling longjmp() in rust is that you can't call setjmp() as a normal FFI function (because it can return twice, like fork(), which is not a normal control flow). Also, longjmp()ing into rust code is just not defined behavior, even if it "works" for now. I assume there are similar challenges in Ada.
> Is the implementation of a Convention isolated enough that it would make sense to be extensible?
Conventions are currently implemented in GNAT as a part of the parser/lexer just like any other syntax element, so it's not easily separated from the rest of the compiler. You could change that behavior, but that's not a small task. I don't think new calling conventions come along very often, so it seems unlikely to be worth the effort.
> One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
I don't know the details of the Postgres implementation, but this sounds to me like the sort of thing that would work well as a generic procedure.
GNAT doesn't use runtime FFI, it dynamically links libraries and maps them into memory the same as any other C program that uses gcc and binutils. I think this makes what you're describing possible, but I'm not familiar enough with how setjmp/longjmp interacts with the stack to be certain without doing more research and testing.
The C interoperability of Ada is very good, you can import/export functions and specify whether records (structs) and arrays must have a C convention. I use it often to access libc and Linux kernel functions/syscalls [1][2].
Can attest to that. C++ is also OK. You still have to write the 'binding' but the compiler can generate a good part for you. Then you can 'hide' all the C-like things (like 'a pointer is an address', 'an enumerated type is an integer', 'you have to call our free() when you're done'...) behind opaque types, controlled types, etc.
As a simple example you can lookup what the compiler generates as a low-level binding [0] that is wrapped in a higher level API [1].
BTW you can also bind Ada to Java (although support is a bit limited I know places where it's in prod). Don't remember if it's a commercial product or oss.
And for the python people, my company financed a first version of ada-py-bind, inspired by the great pybind11. Still a lot of code to write (or generate) but it works fine.
This is more of a general question
With the availability of free languages such as
Rust, Clojure, F#, Go, Typescript, Idris, Raku
You have a solid option that cover ever possible paradigm and style of programming you may fathom
Why would any one invest time or effort in a commercial language such as Ada, Eiffel or even Xojo and LispWorks, that require you to pay for Automated test support and what is considered by most standards now basic libraries
And not only that, the communities are usually tiny and support is probably very limited to the commercial support they provide, and when it comes to languages, languages with big communities, provide infinitely better support than commercial support for proprietary languages or implementations
The cost of AdaCore is not just the compiler license, its the total ecosystem cost
Ada is not a a commercial language. It's free, and the standard is free as well.
Adacore's support is excellent - you're talking directly to gcc/gdb devs. There is no intermediate layer. I've hit a number of nasty technical issues ( compiler bugs mostly), usually fixed within 48h. They then provide you with what they call a 'wavefront' which is essentially a patched version of the compiler which is supported as well.
It is true that the ada community is small, but there is no real other contender in that space ( embedded, formal verification, qualified toolchains, etc).
Edit: nvidia uses spark/ada (from adacore), it's not clear to me what other options they might have given what they want to do (video presentation in the link)
And to be clear they also support C on GCC, so our gcc bugs go there too. Also very very happy with AdaCore's tech support. Response within the day, help and patience in reproducing problems, and almost always with a quick workaround. Often citing the reference manual. You also often have an expert jumping in to help, or to answer a question, or to implement some optimization :-)
I still have fond memories of (the sadly late) Robert Dewar answering a ticket of mine 'this is so slow, whyyyyyyy?' with a 'we have implemented a change that should improve the performance of your code' so fast I hadn't had the time to go talk to our local Ada guy for an alternative idea.
They also have world experts in formal methods like Yannick Moy and Claire Dross who will help you prove you jump-start a Spark project and are pushing the state of the art every year (proof of floating point code, pointer/ownership...).
Money well spent.
And to be clear: not from AdaCore, just a customer.
Rust is not yet ready for formal verification, along with some ready libraries for that purpose, unlike Ada/SPARK. Hopefully, it will be there, just not yet. It still requires tremendous multi-year effort to finish that.
In addition to lacking formal verification tools, I'm worried about compiler certification with a language that changes as fast as rust, and c++, and even c now do. Yes you cannstick to a version, but the world and bug fixes, and libraries will pass you by. Which brings up another problem with rust for safety critical. The stdlib is so very thin, that doing almost anything requies a dependency tree of a dozen or more crates by different authors. You need to certify all those as well. Its a nightmare of an ecosystem from the safety cert perspective.
Many cases when you want cert will probably be nostd anyway so it is definitely worth pursuing given all the other advantages the language has. I'm just being grumpy because I love the language but I am a fan of batteries included languages. Or at least a thick stdlib and a boost-like thing. That is partly influenced by my primary dev environment being airgapped, and my secondary one being behind nexus/solarcube.
Ada isn't a commercial language, though AdaCore's implementation is. Just like Green Hills compiler implementations cost money, sometimes the commercial implementations offer features/guarantees/support the open source implementations do not.
By the way, the test suite, ACATS is part of the standard and is freely available. Not enough for an industrial strength compiler, but amazingly detailed already.
> This is more of a general question With the availability of free languages such as Rust, Clojure, F#, Go, Typescript, Idris, Raku You have a solid option that cover ever possible paradigm and style of programming you may fathom
> Why would any one invest time or effort in a commercial language such as Ada,
(1) Ada isn’t a commercial language
(2) What other free language covers the style and paradigm Ada addresses? Rust maybe (I haven't really done a detailed analysis) now subsumes Ada, but has a different focus and a lot of cognitive overhead related to that focus. Haskell or another static functional language with a robust type system might provide an alternative approach to some similar benefits, but not the same style and paradigm.
It probably doesn't make a lot of sense for a greenfield project, but for established projects it might make sense to stay with the current technology stack. At my last job we had a team of 10+ domain experts that were expert level at a proprietary language. Replacing years of work to save $10k per developer every year would have been a bad decision.
Perhaps companies and individual with an interest in a permissively licensed Ada ecosystem should step up and create it? Build it on top of LLVM and call it, say, alang.
>> Perhaps companies and individual with an interest in a permissively licensed Ada ecosystem should step up and create it? Build it on top of LLVM and call it, say, alang.
If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
> If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
In the same way that "the" C/C++ LLVM frontend is called clang and the Fortran frontend is called flang. So a hypothetical Ada frontend could be called alang.
Interestingly there was, in the first days of clang, an Ada 'compiler', through dragonegg. The original author meant to write an Ada compiler on top of llvm and translated (iirc) gcc's gimple to llvm, with some success.
The fun part is that dragonegg became an important part of clang/llvm for years (before it was phased out) to compile fortran (before flang) and to compare clang results and gcc's. I seem to remember other interesting uses but my memory is failing me.
Duncan Sands (the original author I think?) is an outstanding engineer and very fun person to talk to.
Well... There's GNATLLVM [0] a project to have the GNAT frontend output LLVM. From... AdaCore. Someone has already beat me to a first wasm example [1] and there's also a first wasm-based Android one [2]...
Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
For the compiled CE releases on their website, AdaCore strips the runtime exception:
-- As a special exception under Section 7 of GPL version 3, you are granted --
-- additional permissions described in the GCC Runtime Library Exception, --
-- version 3.1, as published by the Free Software Foundation. --
So yes, binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms (eg. if a customer using these binaries requests the source code)
You are of course free to build the compiler yourself, or use the Ada compiler that comes with your distro.
The sources are available, you just don't get a tag that tells you which exact combination of files AdaCore used to build and verify their binaries.
This is a strategic PITA, and AdaCore have in recent years made some moves to improve the situation, with being active on github and responding to issues in general.
You seem to have various misconceptions; I suggest you consult your legal advisor.
> Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception; the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
> So yes, binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms
This doesn't have anything to do with source or binary version. The reason is that the binaries provided by Adacore are compiled from their (most recent) source version which they publish under GPL without the runtime library exception. For this (and only this) reason you create a "combined work" when you link your code with the Adacore version of the runtime library. This doesn't change in any way if you compile the GNAT version of Adacore by yourself; you still don't have the runtime libary exception which only Adacore can give for their contributions.
> Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception.
Indeed.
> the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
AdaCore contributes to GCC, with some contributions copyright FSF, some copyright AdaCore.
AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
Whether it is more current or not is not relevant to the discussion, and given that GNAT CE has release cycles of 1 year it stands to reason that FSF GNAT gets bugfixes that GNAT CE will only get in 2022.
> This doesn't have anything to do with source or binary version.
I'm now pretty convinced you're reading things that I didn't write.
You seem to be under the impression that dual licensing only works because AdaCore GNAT contains newer files.
However, AdaCore can download stock upstream gcc, remove the linking exception from files they hold copyright over, and distribute this result in source and binary form on their website.
This is due to their unique status with the FSF, something that other companies and private contributors can not do.
Finally, I have never suggested recompiling AdaCore GNAT CE sources will result in a GNAT compiler with runtime exception.
Instead I've pointed out the mechanism of how they achieve this dual licensing: A) unique status as copyright holders alongside the FSF B) strategic inclusion or removal of the runtime exception in each and every file they hold copyright over.
> AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
No "private agreement" is necessary. It's just about whether Adacore grants the runtime library exception for their contributions or not. And they apparently only do that with a delay (a year or so).
Watch out! If you compile the Adacore version of GNAT then you're limited by the license they give you for their version which is GPL without runtime library exception. This doesn't change when you compile their code. With some delay (a year or so) Adacore releases their versions of GNAT with runtime library exception so it can be merged with the FSF version of GNAT.
It's crazy how you are downvoted and people who are downright uninformed both about the licensing and the legal issues are upvoted.
Last time I used Ada, around ten years ago, the situation was exactly the same. This goes to show that the licensing issues around GNAT continue to hamper the ecosystem, contrary to what Adacore like to suggest.
Recently, study results were in the press (e.g. https://www.sueddeutsche.de/politik/pisa-studie-lesen-fakten...) according to which the young have more and more trouble distinguishing between facts and opinions. And everyone and their dog seems to have an opinion on everything, whether they understand any of the subject matter or not (people even seem to resent it when you have relevant qualifications and point them out). So it's no surprise that there are random votes.
> binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms (eg. if a customer using these binaries requests the source code)
You'll be violating the terms that allow you to use the compiler if your source code isn't GPL licensed. That doesn't mean your source code is automatically converted to GPL. It just means you don't have a right to use the compiler or to distribute the binaries you've produced with it.
Using a compiler whose code is under GPL doesn't make your code GPL. But using the GPL runtime library might be an issue. The FSF GNAT version has a runtime library exception which allows you to use the runtime library in non GPL code. The Adacore version has no such exception (at least it didn't when I checked last time).
> But breaking GNAT's license doesn't make the software created GPL
If you do not comply with the terms of the GPL license you're no longer allowed to use the code/software licensed under GPL. Under GPL 2, you can continue to use the code/software after the license violation is removed. Under GPL 3 the copyright holder might terminate your license (see section 8 of GPL 3).
Even then there can be a question of whether your code is derivative of the runtime, or of the standard. If the latter, then you might escape the licensing quagmire
I don't think you can use Ada without dependency (i.e. making a combined work) of a runtime (maybe someone knows a good way without sacrificing relevant Ada features, I don't).
The basis of derivative work, even when RMS was bullying projects with it, was whether your code was dependant on the GPL implementation, or say, could just as well be built with another vendor's library - even if that one was GPLed too, so long as it wasn't derivative of the first runtime.
Essentially a case of "coding for standard interface offered from multiple sources where the interface itself isn't GPL" vs "Your code requires rework in order to work without this specific GPLed dependency".
This is all grossly simplified, but among other things, it means that separating GPL code to another binary you talk over any form of IPC doesn't necessarily mean you're avoiding GPL.
> whether your code was dependant on the GPL implementation
It's rather "whether your work", not only your code. GNAT generates runtime library dependencies even if you are not aware of it. So the result is a "combined work", because the runtime library is linked to your code (otherwise your application wouldn't work).
> breaking GNAT's license doesn't make the software created GPL
This is an important distinction.
But it's still true, that using the Ada core GPL Ada compiler, which does not come with lgpl/run-time exception - you can only legally distribute binaries under the GPL (or commercial license).
This does not matter much if you don't distribute code to others (eg: break system of a car - gpl/commercial; build a web server to sell/stream movies - gpl/internal use).
I still think it's probably a mistake to have the fsf and Ada core version be so similar, yet differently licensed (because it is confusing - most are used to gpl compilers comming with lgpl/runtime exception, like gcc).
I am learning SPARK2014 and it is this confusion around the GPL that gives me pause in fully committing to this direction or any other GPL-licensed software, mainly due to not fully understanding how I can use the Gnat Ada 202x compiler. I am learning Zig, and it is MIT (expat) licensed, which I feel more comfortable in accepting. Rust is the same (dual-licensed MIT/Apache V2), and I think given some people comparing Ada to Rust for high-integrity software are going to gravitate to Rust instead of Ada. SPARK2014, a subset of Ada, is an amazing language for these endeavors.
> You can build gnat and gnatprove yourself, including runtime exception.
How does that work? Are the binaries from Ada core (not FSF) intentionally distributed under GPL while the source for standardlib/run-time come with LGPL/run-time exceptions?
It was my understanding that the Ada core distribution is full GPL only, and the FSF one (lagging a few versions) was licensed more like gcc?
I am more of an end-user here trying to use SPARK2014 for applications, not doing any unnecessary software engineering or builds outside of using SPARK2014 and a compiler. It is this type of thing that makes it a bad choice for someone like me who doesn't have the time and sometimes the wherewithal to build my own compiler. Sure, a simple build of source without licensing restrictions, maybe, but not much above just using the PL to get a job done. This is why I will never give up C and the tools around it, well, maybe Zig or Rust, which I am playing with, but they are nowhere near SPARK2014/Ada for all that you get with them and the Gnat compiler. I was introduced to SPARK2014 with the book, "Building High Integrity Applications with Spark". I also read a fantastic book, "Analysable Real-Time Systems: Programmed in Ada" that put me on this vector. Great stuff and timely.
SPARK2014 is just a tool (gnatprove), which you don't distribute to others (would be rather pointless). Compiling can be done with gnat from your Linux distro, which usually has the Runtime Library Exception.
But if you're going to use the FSF version, why not use fsf/distro binaries? Getting the source from Ada core still leaves you without the runtime exception? (Ada core is upstream/newer, fsf is downstream, lagging a bit behind Ada core(?)).
This issue has been discussed for decades over and over and there are still people like you claim that I'm wrong.
I am not wrong. The runtime of the Adacore Community edition is under GPL, as are many libraries included in the Adacore edition that are not included in the FSF edition. Your binaries will be under the GPL. (Technically speaking, you could compile executables with this version of GNAT that are not under GPL by writing your own runtime. Practically, this is pretty much impossible and nobody has ever done it.)
The FSF edition allows you to compile executables without license encumbering, because it is licensed under the mGPL.
All the things you write are true, except when you claim that the binaries will automatically be GPL.
The author has to make them GPL, in order to comply with the license, that's true. But they don't magically become GPL if the author refuses.
If the author doesn't comply, Adacore can sue them. They can demand that the author stops distributing non-compliant binaries. They can demand that the author pay them money.
They cannot, for example, redistribute the binaries themselves (against the author's wishes), under the theory that they "should be" GPL.
The court probably wouldn't even order the author to put the binaries under GPL, because specific performance is generally not considered by the courts, when paying damages is a workable alternative.
That's probably the worst case of nitpicking I've ever encountered in my life. Yes, you're technically correct. It's not as if you're telling anyone something new, contract law exists for a while already.
I wrote the comment because many people don't know the difference between the FSF version and Adacore's Community Version, hence will involuntarily violate the GPL.
I'm neither paid not misinformed. There is no runtime exception for the Adacore Community version, it is under GPL including the runtime, hence every executable produced with it is also under GPLv3.
If you want mGPL (with the runtime exception) you need to wait for the FSF version.
This is well-known in the Ada community, but I thought I'd mention it because occasionally people don't know the license conditions of various GNAT versions very well. Such as you.
GMPL and mGPL are acronyms for the same exception, the former is just the informal term. It's the GNU Modified General License. People have been calling the license of the FSF version "mGPL" for more than a decade at least.
There is a commercial license to help encourage the big well funded customers to pay for the tools they need to compile millions of lines of company confidential ADA.
And a license for only open source software; just in case students or hobbyists want to write their own robust open source rocket guidance system and share it on github.
There's some nuance here and I don't think this is correct. However, the uncertainty around Ada licensing causes a lot of people to be hesitant to start with Ada.
No, it's not. It's the difference between the FSF version and this GNAT 2021 Community Edition by Adacore. The FSF version is under mGPL, this edition is under GPLv3 including the runtime which is included in every binary.
I mentioned it precisely because people get it wrong so often.
Debian/Ubuntu: sudo apt install gnat gprbuild
Arch Linux: sudo pacman -S gcc-ada (get gprbuild from the AUR)
NixOS: https://github.com/fluffynukeit/adaspark/
I think it's also available on Fedora IIRC.
And then go to https://learn.adacore.com/ :)