Yeah, saw that years ago, but didn’t like the c look of it, read the linear types thing then and then again the other week as I couldn’t remember any of it. Found that they use a c like syntax for the description not the actual syntax, weird.
Not sure linear types are all that great, seems really faffy, but will need to experiment.
Yeah, know of Bush/Sparforte, bus as this topic says, this is supposed to be for investigating a new language which could take over and maybe not have the baggage of Ada.
Yup, Jeff mentioned King to me in one of the first meetings, I looked at the syntax of King in Titania.
See above.
If there’s something they do that you know of, which Ada doesn’t, mention it here.
A successor should have have extensive contracts, static analysis and formal proofs backed in it from the get-go, instead of being a subset like Spark. No feature should be included that doesn’t lend itself to that, or at least they should be easy to isolate in the code so that analysis of the rest isn’t impaired.
The one and only thing that I love about exceptions is the neat way that you can immediately handle system generated exceptional conditions like constraint_error and storage_error.
If I am honest. I expect that unless Gnat code is used as a base then this project will end up being worse than Ada but good luck.
TL;DR — The ARG is very hesitant to remove features, but also [mostly] unwilling to do the work to make more abstract constructions that would allow removing/obsoleting those features, even if acknowledged as a mistake. (e.g. The containers and proving, the containers and user-defined indexing, both make the source [esp.spec] unwieldy and more difficult to read.)
One problem is the above, another is bootstrapping (GNAT is difficult) — I’ve done work and laid out a plan for addressing bootstrapping altogether…
Why would you ditch exceptions ? Surprises or asynchrone control flows are natural part of programs. With this and the wish for removing global states (meaning global variables, right ?) I think Aural’s author must have been high on functional weed. With Exceptional_Cases, exceptions are no longer “surprises” but expected situations with no loose threads.
Because they complicate the runtime requirements and because handling them can be easily missed by accident especially from layers of library code. In this authors case he seems to be trying to go super simple to make flow analysis as easy as possible. Not a language that I would use.