I plan to ideate more on having a similar kernel for swift just like we did for C++. I say this cause I see quite some similarities
A) For C++, we used clang-repl (based on clang & LLVM's ORC JIT and for this we compiled clang & lld using emscripten)
I see swift offers a repl too built on top of lldb (although architecturally different from clang-repl , I would like to ideate a bit on this)
I would like to discuss more here but being new to swift I have quite some doubts. I tried looking on swift's github trying to locate people/teams responsible for maintaining the swift REPL but wasn't successful.
As a first step could someone point me to the maintainers for this project so that I can put forward my doubts ?
This has been done before (incidentally, I was involved in 2 such attempts in the past). The first one was based on using LLDB directly via swift-jupyter as part of Google's Swift4TensorFlow project. The second attempt was based around the new VSCode notebook model.
The LLDB project itself is maintained as part of llvm.org; we do have a fork of it primarily maintained by folks who are already part of the LLDB community.
If you want to pick up the work that I had started for the VSCode based approach: VSCode jupyter notebook based REPL is the post and it links to the original PR.
I see the Swift Repl is probably a wrapper over LLDB (and this LLDB is maintained as a fork from llvm)
So my next questions is
Is it documented somewhere as to what efforts were taken by people working on the REPL to have this separate fork on lldb under swift ? After making the required changes on top of lldb what effort was taken to write the swift repl ? Would it make sense to push this work upstream ?
I'm not sure what the question here actually is intending to ask. LLDB requires forking because of the additional language mode. That language mode requires having the Swift compiler, which is not upstream. While it would be ideal to have the language support in upstream LLDB, that is a massive undertaking.
What work are you referring to? The basis for the REPL has been upstreamed, and others in the community have used that to build additional REPLs, such as the one that mojo has.
Again, this is very unclear. Who is the actor interacting with the REPL. If you look at the code in the pull request I posted above, there is no library in the middle - it is simply communicating over stdin/stdout.
If this is in context of implementing a jupyter notebook, I would recommend against that. My experiences with writing a jupyter notebook kernel with the C++ APIs was that it is far too fragile. That is why the VSCode notebook approach dooes the direct communication.
I'm not sure what the question here actually is intending to ask
By this I meant if it was documented anywhere as to what efforts were taken to come up with the swift repl once lldb was forked.
Who is the actor interacting with the REPL
Let me explain what I wanted to convey here. When I say “interact with the REPL,” I mean interacting with the interpreter that the Jupyter Kernel Protocol hooks into.
For example, in kernels for languages like C++, R, Python, or Octave that use the xeus framework, xeus handles the Jupyter Kernel Protocol part. As the docs put it:
“xeus is a library meant to facilitate the implementation of kernels for Jupyter. It takes the burden of implementing the Jupyter Kernel protocol so developers can focus on implementing the interpreter part of the kernel.”
C API exposed via Rinternals.h / Rembedded.h to evaluate R code.
xeus-python Interpreter: CPython runtime via the Python C API
In practice, xeus-python calls into IPython’s InteractiveShell (a Python object) through pybind11.
So in all these cases, the “interpreter” you implement in C++ is really a bridge:
On one side, it receives code from Jupyter via xeus.
On the other side, it calls into the native REPL API of the target language to run that code and return results.
So basically what I wanted to know is
If swift repl was based on a “SwiftInterpreter” class as such ? and if there is some way to interact with it through an API (for parsing and executing)
That being said according to the stuff I went through I understand that the swift repl is based on the concept of a “debugger” more than that of an “interpreter” (correct me if I am wrong)
I am still exploring more if I can find some proof of concept for a xeus-swift Kernel.
Yes I have been educating myself with the “debugger as a REPL” concept these days.
So I guess we can confirm
There’s no interpreter class as such being offered by Swift.
There’s no C++ API as such to interact with Swift repl and If I am looking to programmatically interact with Swift's REPL, I'd have to use LLDB's C++ API rather than anything provided directly by Swift.
There’s no C++ API as such to interact with Swift repl and If I am looking to programmatically interact with Swift's REPL, I'd have to use LLDB's C++ API rather than anything provided directly by Swift
Unfortunately there is no API at all. You would need to launch the lldb process in repl mode and communicate with it via stdin/stdout.
Not sure if this can be put to use, Probably its not maintaining an incremental state or persistent variables (as maybe what clangInterpreter does for clang-repl) and is only meant to compile one chunk of Swift and run it then ?