proj-oot-ootInterop

See also ootFfi

It should be easy to take an existing program written in, say, C or Python, one which you are currently working on, and decide that you'd rather work on it in Oot instead, and just switch to Oot without throwing out the existing code.

Oot should be a good language for "looking thru" an interpreter. E.g. you should be able to (easily) write an emulator of a VM in Oot, and then, within that VM, run an interpreted or compiled higher-level program targetting that VM, and then (to the extent that the conventions of the higher-level language interpreter or compiler are understood by the programmer) easily write a debugger in Oot that can dynamically inspect the variables (and decompile the code of) the higher-level program for easy viewing and modification.

The facilities to make this easy will also make interoperability easy, e.g. Oot could in theory be programmed to emulate both the JVM and the Python VM and then to transfer data from the JVM variables to the Python ones and vice versa, or even to thread control between them, allowing one to call th other and vice versa.

Interop target languages/platforms

The Oot project has chosen a few languages for which interop is supported as part of the core Oot project:

C, Javascript, JVM, Python, asm.js, webassembly

Why did i choose these? C, JVM, Javascript, and .NET are very popular platforms. Haskell is very different from the others and so will cause us to create powerful and general interop mechanisms. Python is there because Python is my personal favorite language, and also because Python and C are, in my reckoning, the only languages which are both extremely popular and extremely beloved. OpenCL? is there because the concurrency we are seeking is currently available in GPUs.

This list may change in the future. High-priority candidates for future interop targets include: Lua, LLVM, Ruby, as well as more specific support for Java, Clojure, Objective-C, C++, C#, Rpython. Other current candidates include PHP, Visual Basic, Golang, Erlang, Rust, although we're open to considering other languages if someone volunteers to contribute and maintain the interop for it.

For each blessed language, the core development project includes support for:

• an implementation of a Oot interpreter in the other language
• an implementation of a Oot compiler in the other language
• an implementation of an interpreter for the other language in Oot
• an implementation of a compiler for the other language in Oot
• call Oot from the other language, autospawning an interpreter and marshalling shared data when necessary
• call the other language from Oot, autospawning an interpreter and marshalling shared data when necessary
• compiler from Oot to the other language, with relatively readable results
• compiler the other language to Oot, with relatively readable results
• emulate the other language within Oot, and 'look thru' the emulator from Oot to access the variables and functions in the emulated program
• emulate Oot within the other language, and 'look thru' the emulator from Oot to access the variables and functions in the emulated program
• do any of these things from one other language to another, with Oot as an intermediary
• what else?

('relatively readable' is to be interpreted as a rather low bar; i just mean, don't unnecessarily convert everything to continuation-passing style or something like that that is especially hard to read)

(in the above, for now the condition is considered satisfied if it pertains with substitution between a language and a core language or platform, e.g. interoping with Core Oot is considered as good as interoping with Oot and vice versa, and interoping with the JVM is considered as good as interoping with Java and vice versa, even if some of the above bullet points are satisfied in different ways, e.g. maybe we compile Core Oot to Java and compile the JVM to Oot, but cannot compile Oot to JVM or Java to Oot or Oot directly to Java. In the future we may tighten this up for some languages.)

Justification for interop targets

• C: this is the standard platform for interop
• Javascript: the only platform that runs in web browsers
  • asm.js, webassembly: possibly 'the future' of running in web browsers
• JVM: the most popular VM platform
• Python: Python is the popular language that we most want to be like, so we expect that many of our users will also be Python users and so will welcome interoperability

Other potential interop targets

• CLR: very popular, second most popular VM platform
• Haskell: useful to try porting to this strongly functional language, fairly popular
• OpenCL?: useful for GPU computation
• Racket: a language designed for language prototyping
• Lua: a language designed for embedding
• Go: supports many platforms, has a scheduler and garbage collector that is the sort of thing we like, fairly popular

Oot interop design todos

Oot interop design toreads

• http://www.fourmilab.ch/atlast/atlast.html
• Guile
• Lua
• DLR https://en.wikipedia.org/wiki/Dynamic_Language_Runtime

Oot optional features

• non-blocking I/O is optional (on non-supporting platforms, calls to supposedly non-blocking I/O will block!)
• timeouts are optional (eg on non-supporting systems, some or all timeouts may be ignored), but only in cases such as embedded devices where they really are not feasible
• actual parallelization (eg the Oot implementation is permitted to run in a single process on a multiple process system and eschew opportunities for parallelization, simulating 'fork' etc)
• encoding support for strings (eg the implementation is allowed to say 'everything must be UTF-8' or 'everything must be ASCII')
• only a subset of the usual concrete representations may be available. This means that:
  • encoding choice for strings may be forced (eg the implementation is allowed to say 'everything must be UTF-8' or 'everything must be ASCII')
  • data structures may have arbitrary size limits (eg maximial size of integers, strings)
  • data structures may have arbitrary precision limits (eg perhaps floating point is supported but not fixed point or rationals)
• only some I/O, IPC, and process control functions may be available
  • eg if the underlying platform doesn't make it easy to implement certain things, the Oot implementation might not implement it
• supporting non-ASCII source code file encodings