ficus 1.0 TODO

[vpisarev]

NOTE: the previous big ticket was renamed and closed.

Now we have some more things to be done to finally release Ficus 1.0 (or at least Ficus 1.0 beta):

1. • [ ] proper stack trace reporting in the case of exceptions, asserts etc. The stack trace should report the original filenames & lines in the original ficus code, not in the generated .c code
2. • [ ] option to generate shared lib (or static lib), not just executable (the only available option for now). In the case of shared lib probably it should be option to compile ficus runtime as a separate shared library, in order to use several ficus-generated modules together in the same final app.
3. • [ ] as a part of the previous item, provide some method to export clean C and/or C++ API instead of ugly-looking mangled names.
4. • [ ] (lower priority, but still important) option to generate binary python module
5. • [ ] (lower priority) dynamic loading of ficus-generated shared libraries
6. • [ ] automatically define platform-specific symbols that can be checked with preprocessor, like OS, CPU_ARCH etc.
7. • [ ] proper handling of complex modules. To avoid ambiguity, probably there should be __init__.fx in each ficus module directory (including subdirectories)
8. • [ ] add pragma pragma "framework:<framework>" to link Apple frameworks easily without using -clibs flag.
9. • [ ] add pragma pragma "pkg:<pkg>" to link packages via pkg-config more easily without using -cflags and -clibs
10. • [ ] partial implementation of Language Service Protocol: syntax highlighting, including inline C/C++ code, folding, jump to symbol definition, intellisense.
11. • [ ] (quite difficult to do) some debugger support, probably we should try to keep the original local variables' names as much as possible and provide helper scripts for GDB to visualize arrays, lists, variants etc.
12. • [ ] better support for records and variants with cases with record attributes; maybe if we have a variant case SomeCase: {...}, there should be automatically introduced SomeCase.t as type for the attribute record. Or some other way to pack and move data for the particular case.
13. • [x] prepare proper string interpolation and the corresponding string() and print() with complete support for Python 3 format.
14. • [ ] automatic printing of variants
15. • [ ] fix bug when some type declarations are thrown away.
16. • [ ] better support for exceptions at C/C++ level, especially exceptions with some attributes, at least simple attributes (integers, strings).
17. • [ ] check once again if return is properly implemented, maybe not
18. • [ ] (much) more unit tests
19. • [ ] some threading without openmp? we will definitely need parallel for & @sync. What about tasks and asynchronous execution?
20. • [ ] round-up the standard library #5
21. • [ ] full-scale "tensor" data type for nd dense arrays, which type is unknown at compile time. That will help to wrap OpenCV better, implement something like numpy and also improve implementation of deep learning inference engine. Also, tensor could be stored on an acceleration device (GPU, NPU), which is a critical feature.
22. • [ ] implement various scalar intrinsics (partially done): round(), floor(), sin(), cos(), popcount() ...
23. • [ ] maybe not for 1.0, but it would be nice to provide some introspection and meta-compiler features usign something like Python decorators. Probably for that we would need a full-scale JIT