Hi guilers! I'm currently reworking my scm to c generator, c-lambda again. So I have things that looks like scheme it ouputs C functions which in some cases can be read in again in scheme via shared libraries. Now I find managing go and so at the same time awkward and knowing that go files are indeed elf files, wouldn't it be nice to incorporate the so file in the guile go file and make sure guile loads it in the initialization. It should be doable if we append the elf sections onto the guile header without braking the distcance beteen them and let guile know about how to treat them.
With this we should be able to actually compile guile scheme via the vm ops to C and then gcc to position independent machine code. The main obstacles to use this is that a) C calls are not tail calls and b) it is difficult to manage the stack as we do in guile and have native code interoperate with vm code. To a) we may take advantage of a trampoline that also makes it possible to manage a unified stack and also have good cooperation with vm code. Of cause we might as well use gnu lightening but just highlight this oppertunity. The real use of such a tool is to enhance for example an environment with rust like features in cases where you want to have better control of the memory and have much less gc. E.g. as much scheme as possible but type checked and with safe memory management that lead to much less gc-stalls and a low level of fragmentation for long running apps + with fast processing with lambdas allocated in the stack or other similar memory safies if one would need it. I really would like to explore a schem+rust combo (and let the rust env have gc features, delimeted continuations as well included) I also want to explore prolog native code which can have optimisations that will probably lie outside of guile's supply e.g. I need to have a calling convention for prolog code and special stack managment suitable for this language. I know that when compiling prolog code to native code the bottleneck will lie in the memory allocation of closures - which can be reduced to stack allocations if one manages the stack in a certain way. When we combine the so files and go files we can create special bindings e.g. we can link in constant scheme datastructures into the c code vie got table dereferencing and even more we can enable scheme like features that let your functions in your c-calls be set! able just like scheme functions are. Stack management with prolog is really tricky because code on the stack needs to be relocated to the heap in order to gc correctly this means that the stack in prolog needs to be a linked list of stack frames some on the stack for speed and some on the heap for not blowing the stack. WDYT Regards Stefan WDYT
