Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
(But if interested, here's some stuff about my systems language, with some actual features: https://github.com/sal55/langs/blob/master/mfeatures.md)
It's hard to define what "the" defining principle for an imperative language should be since there are many kinds of imperative languages, including some in your list. However, if we instead rephrase the question as, "What would a language look like if it only consisted of side-effects?", then a case could be made that stack-based languages such as Forth (or for a more modern example Factor) come closer fitting the bill than many. The big idea is for these languages is: "every program is just a sequence of operations applied directly to the data stack". This is in contrast to most languages where manipulations of the data stack are usually implicitly handled by the compiler as you define and possibly mutate local variables. The consequence of this is that you have to be constantly keeping track of the state of the stack in your head. Furthermore, if you want to do something to a value (like incrementing it) while still keeping it around, you have to insert dup instructions into your code to make an additional copy of the value before your consume it.
Another example is imperative control flow. OCaml and SML only have basic loops, they don't have returns, breaks, continues. You can simulate them with exceptions, even in a generic way if you use some higher-order functions. Getting good performance for these kind of returns would rely on inlining this function and optimizing local exceptions, which OCaml probably doesn't do as of now.
Well, following the idea of iterators, and looking at my lang, I think relational operators hint at something: