-
Notifications
You must be signed in to change notification settings - Fork 3
Project Roadmap
This page contains a list of all the major work considered remaining for a 1.0 launch of the Epoch language project. Work items are listed in no particular order, so dependencies and optimal paths to completion probably exist but are not explicitly cataloged here.
More detail may be added to specific work items as time goes by. Sufficiently complex features or areas of functionality will be split into separate pages and/or Issues.
These are areas of the language itself considered vital to success. In many cases the base functionality exists in 32-bit prior implementations but needs 64-bit porting; in other cases much work remains in designing syntax and linguistic semantics.
Support for contiguous allocations of data objects is a high priority for future work. Syntax and semantics need fleshing out and there are some order-of-operations issues with how this is integrated into the actual compiler toolchain.
The plan is to expand the prototype BGFX library integration once arrays are in place. Emitting PDB debug data is another high priority candidate for demonstrating array usage in the wild.
End of 2016 Update: Statically allocated arrays of fixed size are now mostly supported. Some parsing and IR support for arrays of structures as well as structures of arrays is still needed. Dynamic bounds checking is not implemented. Overall, the groundwork is largely established but plenty of work remains.
64-bit type-based pattern matching (aka sum type decomposition) needs to be finished. Underlying this is work on the 64-bit implementation of sum type objects themselves. Inline pattern matching and value-based dispatch also need to be done.
End of 2016 Update: Most cases of type dispatch via function overloads are implemented. There are some edge cases that need attention but enough is functional to write working code. Inline dispatchers and value-based dispatchers still need to be built.
The Epoch task model needs extensive design work prior to inclusion in the language. It is likely that a 1.0 candidate could be shipped without tasks for the sake of expediency.
Calls into DLLs are supported but do not have GC integration yet. Callbacks from DLLs are presently not supported well on 64-bit Windows. GC pinning will be an important component of finishing this work.
Exporting Epoch code from a DLL is also an area that deserves attention, since it would allow simpler usage of the parser/compiler service code from other clients, such as the Visual Studio extensions.
This is prototyped but currently blocked on emission of debug metadata. In particular, array support and language-level serialization assistance are strongly desired. PDB data needs:
- Types
- Function parameters
- Local variables
- Correct source-line mappings
The third-generation Epoch GC is a paper design at this point but has no prototype or reliable implementation. Optional GC support is expected to take the form of a plugin library instead of a language-integrated feature.
Metadata is not presently emitted into binaries, making collection impractical. Once this hurdle is crossed, stack walking needs to be rewritten in 64-bit, and then heap tracing. Finally, the allocator and collector code needs to be updated for 64-bit.
Additional work for 64-bit porting includes:
- Eradicating the runtime library dependency
- Porting the compiler to a 64-bit project
- Completing self-hosting of the 64-bit compiler
There is a handful of stuff to do here:
- Polish implementation of MSBuild support
- Clean up legacy
.EPRJproject file format - Add UI option for GUI versus console-mode binaries
- Add file associations in WiX installer
- Temporary objects belong in
obj\x64\$(Configuration)ideally (N.B. the PDB output belongs next to$(OutputName)) - Fix the "Clean" build task to properly remove all temporaries
Smart indentation and automatic formatting would be a strong plus.
There should be a set of configuration options for the syntax highlighter color choices. Moreover, various sorts of data types should be differentiated clearly: structures, sum types, weak aliases, strong aliases, and primitives.
Structure member hints are strongly desired. This requires implementing metadata in the parser that is scope-aware. Initializations (variable definitions) and parameters need special support.
VS extensions in general need some polish and refactoring.
A number of old issues lurk in the Issue Tracker from ages past. More are undoubtedly hiding. The compiler needs a good set of tests for robustness and effective recovery from errors. This includes setting up a strategy for emitting useful diagnostics from both parsing and semantic analysis.
At some point it will probably make sense to institute bug bounties or some similar collective effort for finding and fixing compiler issues.
Eventually it would be nice to explore doing a VSCode extension in addition to the core Visual Studio extensions.