feature request: Multi coding language support about wolfram-js-frontend

[JerryI]

CodeMirror supports mixed and multicode syntax highlighting. However for the autocomplete (or autosuggestions) it might be tricky, there is a packet from Wolfram called Language Server, which provides Lang docs onfly via TCP, which can be redirected to websockets.

One has to be careful, since the front-end and the cell structure highly depend on Wolfram backend and designed for that. Then, any other kernels (js, python) have to be connected to the Wolfram Engine first via Link library

[userrand]

One has to be careful, since the front-end and the cell structure highly depend on Wolfram backend and designed for that. Then, any other kernels (js, python) have to be connected to the Wolfram Engine first via Link library

I am not referring to direct communication between mathematica and other languages via library link. I meant that notebook cells belonging to different languages would be completely independent, no library link involved. On top of that the community can include translators if they want and add it to a separate repository but the default behavior would be independent kernels and independent languages just in the same notebook for the convenience of copy-pasting results.

Basically, I would like to know if there are parts in the code that are strongly hard coded that would not allow adding more web sockets to other languages independently of the presence of Mathematica.

It seems you can already do this with JSRun but I would like syntax highlighting and documentation. The same for python. I can look into this but I wanted to know if the present code has parts that prevent adding another language or that make it difficult

[JerryI]

I see. In principle, the master kernel, which serves the page, takes care about saving notebook and so on has no idea, what was evaluated. It feeds the string to so called xEvaluator with a callback on creating a new child cell, which can be a remote kernel, any kind of process in theory. In this sense, I would not suggest to get rid of Wolfram kernel fully, because someone would need to do all this supporting stuff. Also the code for the making cells depends on WSP extension for Wolfram Engine.

Expanding the frontend to any languages I can see the following problem pop up

• Graphics3D and other possible implementations of interactive objects from Mathematica will have to be recreated in Python or any other languages. I follows the paradigm of Wolfram Language, that everything is a symbol, which is not a part of all programming languages.
• TableForm and others now is a part of frontend, of course, one can get rid of them and move to the sort of extension, but in the end the resulting frontend will be the simplest REPL machine with cells and no other fancy stuff.

Summering all of this, at this stage this project might be still too small and young to pretend to be a multitool, as you described. Bringing Dynamics might involve some architectural changes, but I will keep everyone up to date with it.

[userrand]

Fair enough. So there is quite a bit to modify to add another language. A the moment it is unclear to me why the tiny web part is so complicated. Using Electron, and node.js I would naively expect it to be no harder than making a multi-language coding website using codemirror. Something like the w3schools website or other websites to learn code.

I would have imagined a more limited cell interface for the python and javascript notebook cells, more like jupyter.

That said I imagine that mathics is mainly sympy, numpy and scipy and mathics still managed to get a mathematica like interface. As such, one could imagine adding a bit of optional syntactic sugar for python and javascript with the possibility for the user or community to bring their own syntactic sugar packages. It would be quite cool and maybe the wolfram language would gain publicity among developers of other languages and wolfram et al would not be too upset about the neat frontend (:.