Hello. Do you use some lisp IDE or just a text editor? Also what IDE you use for c++? How do you find the definition of lisp functions, variables, etc.? Thanks.
For me, I use VSCode to develop GNU TeXmacs. And because GNU TeXmacs depends on GNU Guile 1.8.x. And I sometimes have trouble to make GNU Guile 1.8.x work on Linux. I develop on the fork of the GNU TeXmacs (Mogan) using S7 Scheme.
Did you translate Guile into S7 Scheme yourself? Was it difficult? Why is such an old version of Guile still used in TeXmacs?
I think that this blog post might answer some of your questions: https://texmacs.gitee.io/notes/docs/scheming.html
I do not understand the issues that need work in order to translate the code from Guile 1.8 to Guile >= 2, as far as I recall they are connected to the fact that 1.8 is an interpreted language and 2 and above is compiled.
Did you translate Guile into S7 Scheme yourself?
It’s mgubi’s awesome work. I made little work based on his work.
Was it difficult?
I’m thinking about how it would be best to approach this. I find it hard to even compile texmacs. But your advice is helpful. Thanks.
I’ve initiated that port. Actually it has been an activity going on for some years, and via various attempts to translate TeXmacs scheme code in order to run on different interpreters. I’ve tried “TinyLisp” at first, and then “chibi”, and realised quite early that it was critical to have a fast interpreter, otherwise the bootstrap of the scheme code at startup would be unbearably slow, just due to time to read and compile all the code (which is huge). My process went as follows: first write the c++ glue code which runs the interpreter and interface with the c++ internals. This also takes care of translating types back and forth between c++ and scheme. Once this is in place one can try to run TeXmacs and look for error messages due to scheme code which has not being properly interpreted. And from here on the process goes via run/find error/patch cycle. It seems inefficient but actually it is a very good practice to learn about the code because it points to the parts which are more subtle and to the mechanics of various sublanguages that are build with macros in order to perform specific operations (like describing the menus, build the UI interface, describe the file system, etc…). Ideally we would like to have a minimal part of the code which depends on the underlying scheme interpreter and which build an interface layer on which then our main code run. Indeed scheme is ideal to construct sublanguages so you do not really have to modify much of the code, but just create a translator layer which adjust some of the language idiosincracies. I’ve tried to run TeXmacs with Chez Scheme (the fastest scheme available at this moment), but unfortunately my code does not run and at some point I gave up. S7 is a pretty good interpreter, but there is still a serious problem with it: we need a patch which speeds up the lookup of symbols and this patch does not seems to be “correct”, in the sense that it might create bugs. I do not understand why but this seems to be the opinion of the creator of S7 and for this reason the patch didn’t made his way to the official S7 distribution. It would be nice if someone study this problem in detail and come up with a better solution or even understand why the patch is needed. With Guile 3.0.7 the guile interpreter has become fast enough to be on par with Guile 1.8.8 so we could think to go back to it. Unfortunately it is not clear to me that it is easy to support Windows with recent versions of Guile. So we are stuck with 1.8. Which is not so bad but we could use some more speed on the Scheme code…