Thanks zorilla1 for starting discord (orby on discord). We've been having a good discussion.
He asked quite a long question, and I felt this was a better place to address it. His comment is below. My responses are sub-bullets.
Okay. A few thoughts on the road ahead, as I see it (in chronological order):
Working with you to document publicly as much of the currently understood design as possible. Some of this seems like you have a pretty clear idea in your head of what it looks like already. Cxt seems basically complete (minus tables).
Yup, this all sounds great. Cxt still needs to be re-written in fngi, but that is definitely in the mid-term future :D
Finishing fngi. Won't elaborate. Lots of work.
haha, yup.
Spor to native binary compiler. This should also only be dependent on civc. We probably really only need to write the first one of these in C for x86-64 (carefully...). The subsequent ones can be written in fngi, as the C spor compiler will bootstrap the others. This should probably just be a proper compiler. Not much point in writing a linker yet. We can just use .o and link with standard tools.
There is someone else who's been talking about contributing to this area (Lucas). I've invited him to the discord.
Designing the fngi standard library. Civc is just for compilation of the C version of the fngi compiler toolchain, right? (I'm actually not sure that I see the place of civc in the final picture). The userspace fngi standard library hasn't been started yet? I like the goal of keeping civc super minimal, just enough to compile the fngi compiler.
Civc primarily came into existence because I was hamstringing myself when implementing fngi by not implementing core data structures like stacks and allocators "the right way" with their own independent test suite. Now, it serves the better purpose of (eventually) allowing C code to interface with fngi through common data structures.
Implementing the fngi standard library in fngi / spor (for x86-64 linux, for now). This should be written carefully to abstract the system specific stuff away from the more general stuff to make it easier to port to other OSes.
Yup, that is one of the main purposes of Roles -- to permit a range of possible implementations of common interfaces in the simplest possible way.
Minor edit: I'm targeting x86 (32 bit). Eventually I may want to allow slots (S) to be 64 bit (and I've attempted to architect things to make that possible) but it is not an early priority.
Once fngi, the fngi standard library, and the first spor -> native code compiler are complete, I think fngi should be ported to fngi (have you thought about civboot build automation?). Then the spor -> native code compiler should also be ported to fngi. Does this jive with the roadmap in your head? Interested in hearing your thoughts.
Absolutely. Per http://bootstrappable.org -- I am a strong supporter in always having a compiler bootstrapped from the simplest-possible C. However, the C backend will (intentionally) fall behind in terms of power when compared to the self-bootstrapped fngi backend. The constant existence of the C backend will (I hope) help keep the necessary bootstrapping code for the compiler lean.
This is all also making the assumption that you actually want to untether fngi/spor completely from the existing software stack. I know you want to maintain interoperability with C, but not sure if you want to be irrevocably tied to C in civboot.
Per above, I always want to maintain a C compiler. However, I don't see it as "tied to C" but rather that it provides pressure to keep the necessary bootstrapper small. Eventually you shouldn't need a C compiler to build fngi, but you should always be able to bootstrap from C.
So there's a lot of other stuff that I think eventually needs to be written in fngi once this is done, linkers, build automation, etc. But that is lower priority.
I've started thinking about the build automation in #14. I actually think this is a pretty early goal, after the initial standard library is done; which IMO can just be string and file manipulation libraries: once you can do those, you can start writing scripts in fngi :smile:
Where I think I can help in the next few months:
point (1) above is a great place for me for now and for the next few weeks. How finished is spor? In particular with reference to (1), if spor could be standardized and I could document it thoroughly, that would prepare me to do (3) while you complete (2).
spor works pretty well for executing things at compile time. Absolutely nothing has been done on the code-generation side besides me trying to design it to allow for inspection (i.e. when calling a function it points to a TyFn dictionary so you have the full metadata available).
I am very familiar with x86 machine code and ELF and I love this kind of low level stuff. (4) is a massive amount of intellectual heavy lifting, which I think would make a great collaborative project, but no point in getting ahead of ourselves.
Many of the issues essentially target this, especially the main one I'm working on #9
Thanks zorilla1 for starting discord (
orbyon discord). We've been having a good discussion.He asked quite a long question, and I felt this was a better place to address it. His comment is below. My responses are sub-bullets.
Okay. A few thoughts on the road ahead, as I see it (in chronological order):
Working with you to document publicly as much of the currently understood design as possible. Some of this seems like you have a pretty clear idea in your head of what it looks like already. Cxt seems basically complete (minus tables).
Finishing fngi. Won't elaborate. Lots of work.
Spor to native binary compiler. This should also only be dependent on civc. We probably really only need to write the first one of these in C for x86-64 (carefully...). The subsequent ones can be written in fngi, as the C spor compiler will bootstrap the others. This should probably just be a proper compiler. Not much point in writing a linker yet. We can just use .o and link with standard tools.
Designing the fngi standard library. Civc is just for compilation of the C version of the fngi compiler toolchain, right? (I'm actually not sure that I see the place of civc in the final picture). The userspace fngi standard library hasn't been started yet? I like the goal of keeping civc super minimal, just enough to compile the fngi compiler.
Implementing the fngi standard library in fngi / spor (for x86-64 linux, for now). This should be written carefully to abstract the system specific stuff away from the more general stuff to make it easier to port to other OSes.
S) to be 64 bit (and I've attempted to architect things to make that possible) but it is not an early priority.Once fngi, the fngi standard library, and the first spor -> native code compiler are complete, I think fngi should be ported to fngi (have you thought about civboot build automation?). Then the spor -> native code compiler should also be ported to fngi. Does this jive with the roadmap in your head? Interested in hearing your thoughts.
This is all also making the assumption that you actually want to untether fngi/spor completely from the existing software stack. I know you want to maintain interoperability with C, but not sure if you want to be irrevocably tied to C in civboot.
So there's a lot of other stuff that I think eventually needs to be written in fngi once this is done, linkers, build automation, etc. But that is lower priority.
Where I think I can help in the next few months: