-
Notifications
You must be signed in to change notification settings - Fork 144
Split implementation into modules #1003
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Teal Playground URL: https://1003--teal-playground-preview.netlify.app |
93f0320 to
586a137
Compare
|
For a generator for a single file, you should be able to do something like the below: Details
local module_to_files = {
['teal.attributes'] = 'teal/attributes.lua',
['teal.checker.checker'] = 'teal/checker/checker.lua',
['teal.checker.file_checker'] = 'teal/checker/file_checker.lua',
['teal.checker.require_file'] = 'teal/checker/require_file.lua',
['teal.checker.string_checker'] = 'teal/checker/string_checker.lua',
['teal.checker.type_checker'] = 'teal/checker/type_checker.lua',
['teal.debug'] = 'teal/debug.lua',
['teal.environment'] = 'teal/environment.lua',
['teal.errors'] = 'teal/errors.lua',
['teal.facts'] = 'teal/facts.lua',
['teal.gen.lua_generator'] = 'teal/gen/lua_generator.lua',
['teal.lexer'] = 'teal/lexer.lua',
['teal.parser'] = 'teal/parser.lua',
['teal.precompiled.default_env'] = 'teal/precompiled/default_env.lua',
['teal.traversal'] = 'teal/traversal.lua',
['teal.types'] = 'teal/types.lua',
['teal.type_errors'] = 'teal/type_errors.lua',
['teal.type_reporter'] = 'teal/type_reporter.lua',
['teal.util'] = 'teal/util.lua',
['teal.variables'] = 'teal/variables.lua',
}
local keys = {}
for k in pairs(module_to_files) do table.insert(keys, k) end
table.sort(keys)
-- populate the preload field so that we leave worrying about dependency order
-- to Lua
local content = {}
for _, k in ipairs(keys) do
local ke = ('%q'):format(k)
local fn = module_to_files[k]
local f = assert(io.open(fn, 'rb'))
local modcontent = assert(f:read'a')
assert(f:close())
table.insert(content,
string.format([[
-- module %s from %s
package.preload[%q] = function(...)
%s
end
]], k, fn, k, modcontent)
)
end
do
local f = assert(io.open('tl.lua', 'rb'))
local modcontent = assert(f:read'a')
assert(f:close())
table.insert(content, modcontent)
end
local f = assert(io.open('tl_combined.lua', 'wb'))
assert(f:write(table.concat(content)))
assert(f:close()) |
f4576c7 to
ad8a9b6
Compare
|
@mbartlett21 I pulled in your generator into |
73883a9 to
28320d0
Compare
|
And here is my shot at a new API for Teal! Bonus stage!: I ported This was very useful in test-driving the API. @euclidianAce I also kept an eye on how Cyan uses the "v2" API, but I didn't go as far as attempt to port it. |
dbc7474 to
b7d0e8c
Compare
4408fae to
a0bbfef
Compare
|
Rebased on top of the latest changes. @mbartlett21 the test updates in #1027 were a lifesaver for the rebase process! |
This was the first big exercise of the new API.
Lua 5.1 and 5.2 (including LuaJIT) have some awkward defaults for the package path: every default paths accepts the `/?/init.lua` variant, *except* for `./?.lua`. This was since fixed in Lua 5.3 (see `lua53 -E -e 'print(package.path)'`). Since the main Teal API is currently under `teal.init`, let's avoid headaches by handling `?.tl` vs `?/init.tl` files consistently in a universal way. (Yes, theoretically this breaks the environment for someone who wanted to explicitly disable or reorder those `init` package paths compared to their plain siblings (and I'm not a fan of such behind-the-user's-back behaviors, but I think this is extremely unlikely and, given what I've already seen in Teal's own CI this changes is much more likely to make things Just Work than to cause any problems.)
* always return LexError, like check * minor tweak in malformed number token
8c982d6 to
800685a
Compare
|
Merged manually! |
This is a long-awaited development; as we get more people contributing, it's about time we split the code into multiple modules.
I must admit I do find editing a single huge file comfortable, but I obviously understand that splitting the code in modules has other advantages, including making it easier for people to grasp the overall structure more easily, and also to exercise multi-module project structure in the compiler itself.
I still want to be able to have a single-file redistributable version of the compiler, so I'm splitting it into a
teal.*namespace, and I plan to maketl.tlbecome an auto-generated single-file version.Steps involved:
tl.tlteal/init.luatlto use split modules insteadextras/binary.shgenerator for multi-file structureextras/release.shfor multi-file structureCloses #549.