Something I wrote up in 2002, minus the autobiographical stuff. I think this predates the iOS and related devices.

On item 5, we recently published a new formalism (the first of what will be an on-going series of papers, actually) that establishes a comprehensive framework for "context-free expressions", which provide a seamless upward integration of regular
expressions to Chomsky type 2; assimilating but significantly expanding the older 1970's formalism, and establishing equivalence results between two recently-developed formalisms for (for lack of a better name) "type-2-ism".

Anything that is type-2-ish, like inter-procedural control flow analysis, recursive schemata, parsing (the formalism is ultimately finely tuned to do an elegant reformulation of both GLR and optimal LR(k), but that's still in the future), etc.

The Future of Operating Systems
From Shinji Ikari:

My conjecture is this “Operating Systems research is dead”
The towel has been thrown in.
There is no excitement, no passion or drive left in Universities,
research departments, or companies to push the cutting edge of OS development.

A perfect lead-in. Thanks.

I (and a million other people) have been toying with the idea, on and off for a very long time, of creating an entirely new computing system from ground level up that represents such a complete break from the 20th century that I’m hesitant to even use
the word “Operating System” to describe it.

These are some of the intended characteristics of the system I have in mind.

1. Radically Event-Driven, Real-Time Architecture
Part of the incentive behind the system I have in mind is to explore the limits of how far one can take an approach that is antithetical to the clock-driven queue-based architecture to one that is – to use the lack of a better phrase – “time-
invariant”. As such, it’s primarily intended for use that focuses on a Single-User + Multi-Processing + Real-Time environment. Quite literally, the entire system is intended to be completely device-driven and at its most ideal level should respect a
principle to the effect:

If Nothing Happens, The System Sleeps

It operates as a Sleeping Barber.

In some ways, this is the resurrection of Oberon, except that its strict adherence to a non-preemptive architecture is compromised.

The basic kernel, itself, may be mere bytes in size.

2. No File System
The classical UNIX-type tree + link based file system is out. Instead, I’m looking at something that would present itself almost like a visual map different sections of which can be panned in and out of a virtual window.

The underlying space is structured much like an infinite-dimensional geometric space, with links joining different parts of it to one another. The links closely mimic the classic web-based hypertext structure, except for the fact that everything resides
in a single underlying space.

Another possibility I’m toying with is to make the full extent of the classical data structuring facilities of a programming language available at the systems level and to use THAT as the foundation for the system’s data organization.

So, instead of maintaining a file structure, the system actually maintains a general data structure.

(There are plenty of efficient ways to maintain potentially cyclic structures, including some I developed but never published, so that’s not an issue).

3. Concurrent Multithreaded Systems Language, Unified With Command Layer Shell The design takes place on top of a systems language and is really nothing more than an embodiment of the language itself. So, the whole “OS” is really just an interpreter. There is a fully programmable shell which provides direct access
to the underlying language.

The use of the word “interpreter” is probably misleading. What I have in mind transcends the boundary between interpreter and compiler. The interpreter may entail run-time compilation down to the native CPU language and linking.

The full extent of the system’s concurrency facilities are present at the source level within the language. The language, itself, is concurrent multithreaded.

4. An Imperative-Functional Language In A Category-Theoretic Paradigm
The language, itself, is specifically intended to embody a category theoretic programming style (much in the spirit of CAML) in its type system, subsuming the whole Object Oriented paradigm within a category theoretic approach via the
generalizations:
Category <- Class
Object <- Instance
Morphism <- Method
Functors <- Conversions
Natural Transformations <- Polymorphism
and other correspondences of a similar nature.

The integration of imperative + functional into imperative-functional is a synthesis I developed in the late 1980’s (when I coined the term “imperative-functional”), and is completely different than the “monad” based approach that came about a
few years later in the literature – but yet subsumes the monad-based approach by providing what might be termed as the “universal” realization of the construction defined in that approach.

5. Algebraic Programming
Much of the language design will rest on a purely algebraic foundation for the underlying control-flow and interprocedural semantics. The language, itself, is really intended to be nothing more than an elaborate calculus for performing algebraic
manipulations on program logic.

The basic algebraic theory is Kleene Algebra. And one of the key features of Kleene algebra is the operation
A+B
which can represent an arbitrary non-deterministic branching.

The underlying language may directly embody non-determinstic branching and, through it, also subsume the basics of logic programming.

The language is extremely small at the core level and mutable. Not even the classic control flow structures are built-in at the core, but are defined.

6. Devices/Stream Integration, Concurrency, “Channels”, etc.
The same UNIX-style integration of devices with streams exists here. More generally, the basic communications primitive is a “channel” structure which entails the following:
read e, X : wait on event e and read any data X accompanying it
write e, X : trigger event e and write any data X accompanying it

All devices are modeled as virtual read and write operations.

7. A Synthesis of a Network and Publishing Layer + Integration of the Web
An offshoot of the basic systems language provides a the foundation for a multimedia environment which goes far enough beyond the XML/HTML paradigm to enable on-line publishing. The network is accessed directly at the language level and the “internal”
web is meant to flow seamlessly into the “external” web, like it does in most recent systems.

8. Applications Primarily for Off-Desktop Real-Time Usage
The ideal installation would be in a system with a flat console that functions like a sheet of paper, which you can even write on as such, except that you can pan, cut, paste, etc. Extremely lightweight, portable, literally a notebook.

It also provides full access to the classical I/O devices (sound, graphics, etc.) and nice add-on features like direct hand-written to on-line publication conversion. None of these are core features of the system, but the description is what I envision
as one of the archetypical installations.

Another standard setup would be a system for use out in the field; like a network link for a commando outfit or the first Mars explorer team; a wearable computer, etc. This has voice I/O, can even operate as a radio or TV, voice command driven; with high-
end graphics (ultimately: holographic animation). Again, none of these are built-in the system, but sufficient hooks for these add-ons are provided by the fact that the kernel at its core level is radically real-time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)