Project status

[dmitrys99]

What is the project status?

Do you want contributions? What kind of contributions do you accept?
Should one file issues for the project?

Should #5 and #16 be treated as roadmaps?

Thanks!

[vpisarev]

@dmitrys99, thank you for your interest and terribly sorry for a long delay with reply. I have not noticed your issue/question, and also many things happened this year, I was completely distracted from Ficus. Currently my main activities are around OpenCV, as we are going (finally) to release OpenCV 5.0 this year or early next year, and also, first of all, around my new job. I will try to slowly get back to Ficus in my spare time probably closer to the end of this year to early next year after OpenCV 5.

Yes, the main things, are listed in #5 and #16. There are several big roadblocks that need to be passed to make the language more usable for serious things:

1. better infrastructure. At least we need a debugger and LSP (see item 7 below).
2. since we now generate C code, the item 1 may require some hacks or maybe a completely different backend. The most obvious candidate is, of course, LLVM.
3. decent tensor support. I was thinking of introducing a dedicated data type tensor (in addition to array 't []). Having such type would help with many things, including neural engine inside Ficus (ficus/lib/NN), OpenCV bindings etc. One of the main goals for Ficus was to provide a nice GPU support (by generating Vulkan/OpenCL/CUDA code). tensor is assumed to be a 'black box' kind of array, which can be located anywhere, CPU or GPU or NPU memory. In OpenCV I'm now designing the very same thing around UMat.
4. in compiler for the better tensor and array support we could reuse some already available MLIR dialects.
5. not strictly necessary, but a very nice to have feature would be interactive mode (a.k.a REPL). It would be easier then to play with the language and potentially enable various nice things like Jupyter notebooks etc.
6. items 2, 4 and 5 will require us to revise a nice and useful feature of current ficus, which is @ccode. Probably, first of all there should be some partial replacement for C, may be an unsafe subset of Ficus (?), to rewrite some of the current low-level code directly in Ficus. Maybe borrow some ideas from Rust? Another approach that can be used together with 'unsafe Ficus' or replace it would be to extract @ccode chunks into separate files and compile them separately using C compiler.
7. Language server protocol is another must-have feature to make coding in Ficus easier. It can be coded independently from other steps, because it does not depend on the backend choice.

There are other things, like decent package manager, profiler, feature-rich stdlib (#5), but in general, I would say, Debugger + LSP [+may be REPL] [+maybe Tensor] would be the ideal combination of new features to call the result Ficus 1.0. How much time it will take — difficult to say.