Polyglot Development Ecosystem Babel

[MarcusSammon]

I have an idea for a polyglot programming environment enabled by the graalvm.

Basically the environment would be a collection of Domain Specific Languages implemented through the graalvm that could each be called by any other language supported by the vm using a set of interchangable primitive data types used to pass arguments and get returns from any other DSL supported by the VM. More complex datatypes could also be passed between languages using a well defined data interchange system. A universal exception system would also be useful. The languages would need to have a common system to call functions from other langugages within the system. All code would run within the same instance of the VM.

For example
A document could be written using LaTeX with Maxima scripts embedded into the document which would output the code required to typeset it. The same could be done with R or Octave.

Or different versions of a music book could be created by defining variables that would alter the generation of fretboard diagrams in a java SVG generation library dependent on the tunings defined in a variable in the LaTeX document.

Generally speaking any language supported by the VM could be used to generate content used by the document. This content could be images generated using svg libraries, statistical data generated by R from a database, textual content generated by AI, just about anything. Languages such as awk or sed could also be a part of the environment so they would be available when useful.

These domain specific languages could be extended to incorporate some of the concepts of java such as Bytecode compilation, standardized folder structure, native compilation, annotations, reflection, and unit testing.

The gradle build system could also be generalized to support languages that are a part of the polyglot ecosystem to ease the build system of a solution that is composed of several languages.

The build system would need to have a library repository for each supported DSL to allow for this.

Babel should be the name of the polyglot environment and the build system could be named Gravy.

[rubyFeedback]

So one question upfront: the DSLs are already implemented? Would this require the specific languages for those DSLs to be used or put into GraalVM?

If I understood it correctly, you kind of would have some kind of semi-universal DSL here right? How is the environment defined or changed though? I guess I am not sure right now of the scope here. Do you have examples for DSLs to be combined here? I don't fully understand the bridging part idea either. Many years ago I was using VirtualDub + Avisynth to manipulate multimedia data, and I loved it. It was almost like Linux pipes back when I was using windows. So I am all up for DSLs and DSL-like environments; I am just not entirely certain about the scope of the idea here.

[MarcusSammon]

The DSLs are already implemented in another language but I was thinking that they could be re-implemented for the graalvm to compile down to bytecode just like Java. The Idea being that if they compile down to the same bytecode then they can communicate directly with one another so long as they have the same definition of primitive types or a general means of declaring how user defined types would be translated into a common form. Any language could be added to the environment provided that it is supported by graalvm and follows the conventions needed to allow communication between languages. e.g. Same definition for primitive types and whatever necessary conventions for the transmission of user-defined types.

If the languages are supported by graalvm then every language used could execute within the same VM because everything would run in the same bytecode(Hopefully the languages could be native compiled also). Maybe I don't understand the current implementation properly but even if I don't, running everything using the same bytecode would be possible to implement.

Also I think it would make sense if any compatible language could be the starting point for execution. Such as a LaTeX script being compiled would trigger the execution of any code in any language used to expand its functionality.

I suppose the scope of the idea would be to have any supported language to be able to transfer information to any other supported language or execute code from another language without there being any real performance overhead. The different languages contributing to the project should be contained within the same project folder hierarchy and the means by which other languages could be called should be restricted to keep the project structured in a sane and understandable manner. Like Java's restriction to one class per file.

As far as the exact details of how the environment would work in an IDE and how other languages are called, that would be decided upon by those implementing it.