Dreaming in a bytecode

[ivan.moony]

Dreaming in a bytecode

In this thread, I want to propose and hear opinions about something different than the current generic programming technology which takes form of JVM and CLI. I have some thoughts on how the proposition could be implemented, but I want to hear your opinions, as well. I wonder if any of this would make any sense.

Thousands higher level languages -> one machine code
During programming, we use general purpose or domain specific languages, possibly calling code fragments written in different languages, finally hitting the compile button, when it all translates to the machine code. The problem with this setup is that there are many different platforms with different machine codes, while traditional compilers targeted only one machine code.

Thousands higher level languages -> one byte code -> only machine codes supported by vendors
With invention of bytecode technology, first in Java compiler (JVM), then in Visual studio products (CLI), things are supposed to get much better regarding to the fact that there exist many different platforms on which we want to run our programs, each encompassing its own machine code setups. Normally, we would have different binary builds of applications we write for different platforms, until bytecode technology was introduced. Bytecode is supposed to be an intermediate product between source code and actual machine code. Source codes would then be compiled into one and only bytecode, while there would exist different bytecode interpreters for different platforms, ensuring that the same bytecode behaves exactly the same on each supported platform.

Oligopoly
But the problem with the current bytecode technology is that it is oriented upwards. We, as programmers community, are supposed to write compilers for different languages into a bytecode of our choice, while bytecode vendors are supposed to decide whether they would support certain platform, or not. It is obvious that this situation gives vendors too much control over the market that should be as much accessible as it can. Currently it is very hard to introduce a new device or operating system because bytecode vendors could easily condition support of such device or operating system.

Proposition: thousands higher level languages -> one byte code -> thousands machine codes
But what if we had a bytecode technology that wouldn't be oriented strictly upwards, towards higher level programming languages? Wouldn't it be cool if we had a bytecode that is oriented in a different direction: downwards, towards different machine codes that are not predetermined in advance? Such a bytecode would be brought in a form of generalization of compiling rules. Such Compiling rules would be alterable by very programmers community which would, when necessary, code a connection between the well known bytecode and targeted machine codes. The bytecode behavior would be known, machine code would also be known, and the bytecode, by its definition, would provide a mechanism for translating former to later.

As an additional thought, we shouldn't consider target compiling environments as strictly consisted of machine codes. In fact, any programming language source code or higher level operating environment could be the target compiling environment, including the very web browser technology we all know about, but also any new, yet unknown, incoming technologies of the future.

Requesting feedback
How much do you feel we are already restricted by the current oligopoly decisions?
Would proposed kind of bytecode philosophy bring any benefits to a global programming community?
Do we already possess technologies needed for implementing proposed kind of bytecode?
What are generally your thoughts on this matter, and are there any relevantly important aspects I forgot to mention?

 

[Krusty the Senile]

This is a "shot off the hip" response, but have you had a look at LLVM? I think that's what the purpose of that project was: provide tools that would transform a programming language to a form of bytecode, then transform that bytecode to machine level code, specific to the underlying architecture. Wikipedia: https://en.wikipedia.org/wiki/LLVM and main page https://llvm.org/

 

[ivan.moony]

LLVM is a very nice product, I've heard only good things about it. But what characterizes LLVM intermediate representation language (just like JVM or CLI) is its assembler-like appearance. And I suppose there are good reasons for it.

But I'm taking a different approach. In contrast, my current research led me to the point where I conceptualized a programming language that can't do nothing on its own, yet it can only be used to describe different target environments, while composing specific customizable target code templates. All this takes only one operator to pair (1) expressions to translate and (2) a kind of propositional logic rules that generally behave like a term rewriting system. This command may be recursively combined and composed, forming a top level source code which describes compiling steps of its elements to target environments.

I had before an idealized version of translating any code form to any other code form, but it turned out pretty messy and cumbersome in my opinion, although I had nothing to compare it to. Anyway, my latest ideas shaped up into the language I got enthusiastic about, but there is a trade off: it isn't anymore translating any code to any other code; now it is having only one specific kind of top code which combines targeting code fragments only downwards the term translation tree.

The new language implementation is conceptualized as a parsing algorithm that, instead of reading source code, actually generates target code from grammar rules written in the language. I'm not sure how much of all of this I'll finally realize, but I'm pretty excited about this idea, and I feel there is a great potential in it.

 

[ivan.moony]

One byte code <-> thousands arbitrary languages

Bytecode that has ability to translate itself to a certain language has one interesting property: it possess all the information to be used in backward direction, to translate any language to a specific subset of itself. To do this, it has to describe every aspect of the language in its terms of syntax and semantics. It isn't very large step from writing a source code to reading a source code using this imaginary bytecode. But that bytecode that stays in between reading and writing could be used as a constant that can be used for a very interesting purpose - it can serve as an intermediate language for translating between any two languages.

All of this means that we could read, say, Python code and write, say, Haskell code. Or we can read C# code and write Assembler code. Or we can read Assembler code and write Basic code. Any combination counts in, as long as we fully treat outer languages as representations of the fix-point: syntactical and semantical definition in terms of the bytecode.

With this conclusion I'm closer to my original idea of translating any code to any other code, but by using the fix-point language, we don't have to describe every combination of each two languages connection, which would be total N^2 different translation definitions; With the bytecode, it is possible to have only N translations that do the whole backward-forward translation.
*(N stands for total number of supported languages)

This may be the point where I have to return and revise my old Logos language concept. In the end line, I might be implementing it anyway.

(I'm including a link to specification describing concept of proposed bytecode.)