List view
With growing complexity of what is possible to be written in pyro, an import system is required. This is a prep-work for the standard library low-level implementation in pyro 0.3.0.
Overdue by 1 year(s)•Due by June 15, 2024Since we should have a structure declarations and a function functionality ready by this point, an implementation of core buildins is on the way. This way we can move from adding hard-coded implementation for some basic types and move to writing new pyro functionality directly in pyro code itself (e.g. raising to power, exceptions, closures/decorators etc.) For this stage, only the types from `buildins.py` should be implemented. This is a first and important stepping stone before moving to more complex parts like python standard library
Overdue by 1 year(s)•Due by June 30, 2024Currently pyro uses no python-based dependencies (except standard library), but for the purposes of the machine code generation we still use NASM. It is a huge dependency to have, and the resulting binaries are quite big. It would be preferable to have a module that takes an in-code representation of assembly and builds a binary specific to the target architecture. This change will require: 1) An ELF format representation in python 2) An .exe representation in python 3) A translator to the binary
Overdue by 1 year(s)•Due by June 30, 2024In order to add more pythonic functionality, we need to work on a basic function implementation in the pyro compiler. At first the function abstraction we will create will not be fully compatible with the python's `FunctionType`, but since in python itself `FunctionType` definition is self-referential (e.g. being a descriptor, which has methods that are also descriptors and so on), we need to draw a line somewhere, where the low-level implementation of these constructs lie in the language
Overdue by 1 year(s)•Due by May 31, 2024•0/1 issues closedSince in cpython everything is an object, we need to implement a basic object data structure into the pyro code, also adding a class definition functionality. This will be the first step before adding other data types and functions, which will open more room for future features being implemented directly in python code compiled by pyro, without making changes to the compiler
Overdue by 1 year(s)•Due by May 31, 2024•3/8 issues closedSince going into compiled territory we have more information on what our python program is doing, it will be useful to add any sorts of optimizations to our representation processing This requires addition of a new step into the compilation process - optimizations. Optimizations must be optional and extendable, so this step requires: 1) adding new compiler execution state - with optimizations / without optimizations 2) adding an optimization class that can be extended without changes to it directly (e.g. optimization framework) 3) writing some basic optimizations for starters. First optimizations to be added are: - unused assignment elimination - constant folding and propagation - dead code elimination (e.g. never used if/else branches can be purged to be replaced with plain inline block)
Overdue by 1 year(s)•Due by April 30, 2024•0/8 issues closedWe need to add compiler functionality and stop using hardcoded strings as a compilation source. For this goal we need to: - Read files from names provided in command line - Add execution flags with target specification - Add temporary debug flags for debug purposes - Restructure the project to allow an existence of a separate compiler object that can be manipulated from the command object (operated from the command line) or another operating object (for the purposes of a demo or embedding in another python project)
Overdue by 2 year(s)•Due by January 5, 2024•6/7 issues closed