From b6794ad9997f34b7ebe5c6767664118b693933f4 Mon Sep 17 00:00:00 2001 From: Brendan Hansen Date: Tue, 11 May 2021 14:01:12 -0500 Subject: [PATCH] small updates and thoughts --- docs/module_thoughts | 27 +++++++++++++++++++++++++++ src/onyxchecker.c | 3 +++ 2 files changed, 30 insertions(+) create mode 100644 docs/module_thoughts diff --git a/docs/module_thoughts b/docs/module_thoughts new file mode 100644 index 00000000..592da54c --- /dev/null +++ b/docs/module_thoughts @@ -0,0 +1,27 @@ +Modules in Onyx +--------------- + +Modules are going to be the form of reusable code in Onyx. They should be a +self-contained (maybe dependent on other modules), collection of Onyx files +with a module.onyx in the root folder that loads all relevant files to the +module. Modules can then easily be included by loading the module.onyx file +of any module. + +Things that need to be decided about modules: + - How should modules be searched for in the filesystem? + - How should javascript code in modules be easily maintained? + Current solutions just copy the relevant javascript on build. + +Things that need to be done in the compiler: + - Rename 'package' to 'namespace' + I think 'namespace' better reflects the way I think about 'packages'. + I don't want it to feel too 'C++-y' but I think the nomenclature change is worthwhile. + + 'package' was orginally inspired by Java, but there the folder structure must match + the package structure. In Onyx, that is not the case because it allows for packages + to be extended on without needing to modify the source of the original package. + + - Add relative file loads and relative #file_contents. + If the string starts with './', it should be considered relative. + This will make it easier for modules to include their files, regardless of + how the project is set up. diff --git a/src/onyxchecker.c b/src/onyxchecker.c index cbae99bd..404e2a77 100644 --- a/src/onyxchecker.c +++ b/src/onyxchecker.c @@ -1010,6 +1010,9 @@ CheckStatus check_struct_literal(AstStructLiteral* sl) { AstTyped** actual = sl->args.values; StructMember smem; + // BUG: There are problems setting the comptime flag this late in the checking because + // if the struct literal was type inferred, then the literal won't be correctly determined + // to be comptime on the first pass, which is needed for top level expressions. sl->flags |= Ast_Flag_Comptime; fori (i, 0, mem_count) { -- 2.25.1