Roadmap

What’s next? Idio is new so there’s plenty to do but there’s also lots that could be done.

Idio wears two hats so we can broadly categorize things into programming language-oriented and shell-oriented areas of interest.

There’s no priority to any of this (unless you’re paying) so it’s more a collection of ideas.

Programming Language

As a programming language Idio needs a lot of work: it’s too big, too slow and doesn’t do enough.

Idio is designed to be extensible meaning that no-one has to update the core engine to enable some functionality. There are reader operators and templates to create syntax and extensions to hook in standalone libraries of work.

However, in some cases, the core is where the effort has to be made.

The Core Engine

Many obvious functions are missing as they’ve not been required, yet. A splice-array function might be useful, say.

A tentative start has been made on values being const and Perl’s concept of an external value being tainted appeals.

The evaluator is currently written in C but has been fully re-implemented in Idio. The Idio variant gets a bit tied up when dealing with templates so it isn’t the default.

Idio implements Scheme-style conditions and their companion behaviour restarts are on the to-do list.

TCL-style safe (sub-)interpreters sound useful.

Compiling modules (to byte code) to be read back in would be expected.

Compiling and/or reading compiled object raises questions about repeatability of compilation, determinism (as in, is that what we expect?) which leads to handling authentication and verification.

That raises an interesting question about encryption – maybe only people who’ve entered into a contract can decrypt a module?

Compilation raises questions about JIT compilation to machine code. Maybe AOT compilation to machine code is worthwhile?

Wider Language Thoughts

With the evaluator written in Idio it becomes considerably easier to implement optimisation during evaluation.

Alongside optimisation, some type analysis, and maybe type inference, would be expected to add value.

Gregor Kiczales’ Tiny-CLOS has been implemented as the Idio Object System in release 0.2. It’s not very efficient, though.

Shell

Idio is missing a couple of shell features but we’ll gloss over that.

screen and/or tmux are useful allies in the war against dropped connections. Those two are both predicated on interactive sessions which is not our thing. However, session resumption calls for some stringent authentication and verification perhaps even down to the use of a shared secret established during the original setup.

Nervous types would like some form of state persistence and secrets would be looking for secure vaults.

Some form of Finite State Automata seems to be a missing link for shells. The idea that you can step up from orchestrating individual processes to managing complex procedures seems to be an obvious move for a shell: handling workflows and decision automation.

• you can imagine Yet Another make Mimic

• you can (better) imagine the start of the whole panoply of Business Process Management

Is there a better form of inter-host command orchestration? At the moment you are more or less constrained to ssh host ... or managing remote agents. How would things work if the far end could report on job status much like Idio/the shell manage and report on “local” job status, except over the wire?