[posterboy]

That REPL is called a command line. Sure, it's not the same, but then it does not run on a virtual machine either (OK, LISP isn't necessarily, either).

You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.

[pjmlp]

That is not even close.

EDIT: I guess I should expand a bit on that answer.

Take Oberon, which like Java has the misfortune of using the same name for the language and the respective OS.

It was based on Niklaus Wirth experience on using the Xerox Star system with Mesa/Cedar environment.

The original Native Oberon used as only executable format shared libraries. Depending on the OS variant, they were either fully AOT, or JITted on load.

There was a convention on procedures that could be made visible to the REPL or mouse commands and what type of input they would act upon.

So you could either do module.procedure parameters at the CLI, select some text at a given open window or embedded object (think OLE) and select a module.procedure at the toolbox of loaded modules.

Very simple set of primitives exposing the whole OS, both CLI window and other GUI elements as programmable elements.

You see a bit of this way of working on the ACME editor used in Plan 9, specially later on Inferno with Limbo.

[posterboy]

> That is not even close.

Stream processing should be equally mighty as list processing. What about system level access?

Edit:

> both CLI window and other GUI elements as programmable

Sure, X sucks, but it supports that. X might be infamously complicated, but there's a security hole, either way.

[pjmlp]

Text stream processing is not as powerful as data structures and functional programming composition.

How do you in X protocol select an object that represents a table in a word document and add an extra column with the standard deviation of the other rows?

Just a possible example of the type of composition that was possible.

[posterboy]

nowadays, theres possibly a related System-D feature ;)