Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: Multi coding language support #5

Closed
userrand opened this issue Feb 3, 2023 · 4 comments
Closed

feature request: Multi coding language support #5

userrand opened this issue Feb 3, 2023 · 4 comments

Comments

@userrand
Copy link
Contributor

userrand commented Feb 3, 2023

Is the code currently built in such a way that one could develop a notebook that has different coding languages (python, wolfram language, javascript) in different cells ? Mathematica already does this but it does not have syntax highlighting and short documentation when hovering over functions in other languages.

This question has already been asked for jupyterlab here : jupyterlab/jupyterlab#2815. The author here: jupyterlab/jupyterlab#2815 (comment) claims to have made an implementation that does that but I did not test it. There is also another claim on the same thread here jupyterlab/jupyterlab#2815 (comment).

This is an ambitious task I am just exploring the potential of the project at this moment.

@JerryI
Copy link
Owner

JerryI commented Feb 3, 2023

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
Copy link
Contributor Author

userrand commented Feb 3, 2023

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
Copy link
Owner

JerryI commented Feb 3, 2023

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
Copy link
Contributor Author

userrand commented Feb 3, 2023

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 (:.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants