Implement modules and require #397
Conversation
VictorNogueiraRio
force-pushed
the
pallene-175
branch
from
8c117c5 to
45f834c
Compare
pallene/types.lua
Outdated
| "field_names", -- same order as the source type declaration | ||
| "field_types", -- map { string => types.T } | ||
| }, | ||
| Module = {}, |
There was a problem hiding this comment.
Can we find a way to not have a module type? I'm happy that we recently got rid of the "fake" types Void and Module and I'm not looking forward to putting them back...
Perhaps by treating the require as special syntax instead of as a regular function call. Or maybe by saying that it returns any.
There was a problem hiding this comment.
@hugomg using any instead of Module works fine, as well.
Just committed this change now.
There was a problem hiding this comment.
Does that mean the user won't be able to shadow require anymore?
perhaps it could be a contextual keyword like async in Javascript.
There was a problem hiding this comment.
As of now, the user is still able to shadow require.
I think that's actually a good test case idea.
VictorNogueiraRio
force-pushed
the
pallene-175
branch
from
45f834c to
3b02c44
Compare
pallene/coder.lua
Outdated
| local imported_func = self.module.imported_functions[upv.f_id] | ||
| modules[imported_func.mod] = modules[imported_func.mod] or {} | ||
| imported_func.id = upv.f_id | ||
| imported_func._tag = "func" |
There was a problem hiding this comment.
Assigning a _tag is strange. Should we create a proper tagged datatype, using declare_type?
There was a problem hiding this comment.
Fair enough, I think it would be better.
| LocalVar = {"id"}, | ||
| Upvalue = {"id"}, | ||
| Function = {"id"}, | ||
| ImportedFunction = {"id"}, |
There was a problem hiding this comment.
Silly question: why do we need separate cases for the Function and ImportedFunction?
There was a problem hiding this comment.
I tried using Function at first and adding the imported functions to the module.functions table, but there are several places in the code that loop through module.functions and expect there to be a body field. Since we are not running the compiler past the Checker phase ( for obvious reasons), the imported functions won't have a body and, thus, the checks will fail. Also, there are places, such as here (https://github.com/VictorNogueiraRio/pallene/blob/pallene-175/pallene/coder.lua#L1719) where I need to generate a different code if it's an imported function. I mean, I could simply put a field in Ir.Value.Function to differentiate, but, would that really be better? The same goes for ImportedVar.
There was a problem hiding this comment.
If the imported functions work differently, I think it is ok to have a separate case for them.
VictorNogueiraRio
force-pushed
the
pallene-175
branch
5 times, most recently
from
25cdc03 to
2098047
Compare
VictorNogueiraRio
force-pushed
the
pallene-175
branch
from
2098047 to
ff4545d
Compare
3 participants
Missing parts:
1. Tests focused on modules2.
Recordsas parameters to module functions