Life after D safe Java Mk III
Java was always designed to function both as an implementation language and an end-user application programming language. The driver for that is to keep the JVM small and portable, but it puts a lot of the plumbing on display in the front parlour. C# is at least as bad: it has pointers, low-level structs, DLL calls. We need them, but they make the language unsafe.
So I propose Safe Java (SJ) as a dialect of Java with a smarter compiler and all unsafe features removed, but still interoperating freely with Java (mix as needed).
Along the lines of:
- The primitive types are boolean, number, string, time, enum, blob. No characters, bits, unsigned, etc.
- Enum is a collection of names that work like strings without quotes. Blob is opaque data.
- Full set of library functions operating on those types.
- Inheritance of primitive and new types (replaced typedef)
- The compiler tracks value usage and may require a conversion (such as round or truncate) eg before a number can be used as an integer, or do it implicitly if safe.
- New types are immutable and have value (copy) semantics. [Mutable types? Use Java]
- No new and no constructors. A declared variable or member is initialised to a default value, or one supplied by the declaration. TTM-like selectors to allow creation of values by setting component values
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
- Reflection is a compile time feature only (see below).
- A harmonised set of type-safe generic collections replacing Java arrays, list etc: start with just list<>, dictionary<>, set<>.
- Streams-like operations on those collections.
- No exception handling. Calls that may fail should return Maybe<>. Unhandled errors trigger a panic, which can be only be caught by unwinding to an earlier proven safe point. (edit)
- Safe multi-threading using async or similar. (edit)
SJ is accompanied by:
- Plain Old Java, for writing low level extensions, and mutable types
- M, used to extend the language itself.
M has compile-time logic including
- Annotation/attribute-like features at compile time (only)
- Types and symbols imported from compiled code (like reflection)
- Types and symbols imported from Json, XML, SQL, etc (export?)
- Type checked template macros (like C++) [sufficient to define TTM shorthands like INSERT/DELETE/UPDATE].
- Iteration over collections of types and symbols
- Name generation using string functions
- Compile-time code (such as calculating TTM heading inference)
Quote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Quote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Quote from Dave Voorhis on May 5, 2021, 8:49 amQuote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Those are separate points.
- loops over collections are always safe, and they are higher, in the sense of collection rather than item..
- Loops with a termination condition are required to be safe, that is written such that the compiler can verify termination.
- For loops that simplify to either of the above might be permitted as syntactic sugar, but other forms are not allowed. Eg
for (i=0;;++x) {...}
Quote from dandl on May 5, 2021, 1:28 pmQuote from Dave Voorhis on May 5, 2021, 8:49 amQuote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Those are separate points.
- loops over collections are always safe, and they are higher, in the sense of collection rather than item..
Better to describe it as iteration over collection elements, rather than "loops over collections" which implies for (i = 0; i < collection.length; i++) { ...set i to zero here, oops... }, etc.
- Loops with a termination condition are required to be safe, that is written such that the compiler can verify termination.
Trivial termination conditions (like running out of elements in an immutable, finite collection) are, of course, trivial but an infinite number of non-trivial termination conditions are equivalent to solving the halting problem.
Quote from Dave Voorhis on May 5, 2021, 1:37 pmQuote from dandl on May 5, 2021, 1:28 pmQuote from Dave Voorhis on May 5, 2021, 8:49 amQuote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Those are separate points.
- loops over collections are always safe, and they are higher, in the sense of collection rather than item..
Better to describe it as iteration over collection elements, rather than "loops over collections" which implies for (i = 0; i < collection.length; i++) { ...set i to zero here, oops... }, etc.
- Loops with a termination condition are required to be safe, that is written such that the compiler can verify termination.
Trivial termination conditions (like running out of elements in an immutable, finite collection) are, of course, trivial but an infinite number of non-trivial termination conditions are equivalent to solving the halting problem.
I'm not sure you quite get what I'm on about. I call it 'loops' in the sense that this is underlying iteration, but the intent is to operate on the collection as a whole so that (a) the compiler guarantees safety (b) the mental process is about the collection, not the elements. Functions like map(), fold() and the RA would fit that bill, in principle. Parts of Linq/Streams. Operations on sets and lists.
Other kinds of iteration such as generating a collection, searching will need other mechanisms to satisfy the compiler that they terminate. The idea is that a loop that might not terminate is a compile error.
Quote from dandl on May 6, 2021, 2:20 pmQuote from Dave Voorhis on May 5, 2021, 1:37 pmQuote from dandl on May 5, 2021, 1:28 pmQuote from Dave Voorhis on May 5, 2021, 8:49 amQuote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Those are separate points.
- loops over collections are always safe, and they are higher, in the sense of collection rather than item..
Better to describe it as iteration over collection elements, rather than "loops over collections" which implies for (i = 0; i < collection.length; i++) { ...set i to zero here, oops... }, etc.
- Loops with a termination condition are required to be safe, that is written such that the compiler can verify termination.
Trivial termination conditions (like running out of elements in an immutable, finite collection) are, of course, trivial but an infinite number of non-trivial termination conditions are equivalent to solving the halting problem.
I'm not sure you quite get what I'm on about. I call it 'loops' in the sense that this is underlying iteration, but the intent is to operate on the collection as a whole so that (a) the compiler guarantees safety (b) the mental process is about the collection, not the elements. Functions like map(), fold() and the RA would fit that bill, in principle. Parts of Linq/Streams. Operations on sets and lists.
Other kinds of iteration such as generating a collection, searching will need other mechanisms to satisfy the compiler that they terminate. The idea is that a loop that might not terminate is a compile error.
How does your compiler detect that a loop might not terminate, in order to generate an error?
By convention, iteration generally refers to looping over the elements of a finite (and either immutable or safely mutable) data structure, and therefore can be guaranteed to terminate. A loop generally refers to any repeated code execution whether it can be ensured to terminate or not.
So to avoid possible confusion or controversy, it might be safer to speak of iteration rather than looping.
Quote from Dave Voorhis on May 6, 2021, 2:48 pmQuote from dandl on May 6, 2021, 2:20 pmQuote from Dave Voorhis on May 5, 2021, 1:37 pmQuote from dandl on May 5, 2021, 1:28 pmQuote from Dave Voorhis on May 5, 2021, 8:49 amQuote from Darren Duncan on May 5, 2021, 7:04 amQuote from dandl on April 22, 2021, 7:55 am
- Loops over collections, while/until, are safe, proven to terminate. No for(;;)
This point is unclear. A "while/until" as generally understood takes an arbitrary boolean-valued expression and is no more proven to terminate than "for".
Yes. And the classic C-style for loop is syntactic sugar over a while loop, anyway. It's merely a way of conveniently putting the while loop initialisation, loop continuation test, and loop state change all in one place instead of three places.
Those are separate points.
- loops over collections are always safe, and they are higher, in the sense of collection rather than item..
Better to describe it as iteration over collection elements, rather than "loops over collections" which implies for (i = 0; i < collection.length; i++) { ...set i to zero here, oops... }, etc.
- Loops with a termination condition are required to be safe, that is written such that the compiler can verify termination.
Trivial termination conditions (like running out of elements in an immutable, finite collection) are, of course, trivial but an infinite number of non-trivial termination conditions are equivalent to solving the halting problem.
I'm not sure you quite get what I'm on about. I call it 'loops' in the sense that this is underlying iteration, but the intent is to operate on the collection as a whole so that (a) the compiler guarantees safety (b) the mental process is about the collection, not the elements. Functions like map(), fold() and the RA would fit that bill, in principle. Parts of Linq/Streams. Operations on sets and lists.
Other kinds of iteration such as generating a collection, searching will need other mechanisms to satisfy the compiler that they terminate. The idea is that a loop that might not terminate is a compile error.
How does your compiler detect that a loop might not terminate, in order to generate an error?
Because it was not provided with enough information to be able to prove that the loop will terminate. For example, any loop with a finite read-only iterator as control variable must terminate.
By convention, iteration generally refers to looping over the elements of a finite (and either immutable or safely mutable) data structure, and therefore can be guaranteed to terminate. A loop generally refers to any repeated code execution whether it can be ensured to terminate or not.
So to avoid possible confusion or controversy, it might be safer to speak of iteration rather than looping.
I'm not sure the Internet agrees with you, but even so that is my point: iteration as you describe is allowed, generic uncontrolled looping is not. In between there are other kinds of safe iteration, and a good way to capture them is as an iterator, which for this purpose must be finite. C# has good support for iterators, but they're clunky to write.
The key thing about iteration in my view is the concept of repetition, going over he same path, as against mere looping. The for(;;), while and similar loops encourage unsafe loops, and should be discarded.