Closed UnsignedByte closed 6 months ago
Thanks for starting the discussion @UnsignedByte! I think there are bunch of things to figure out and we can solve the smallest problem first:
Supporting different top-level/external modules: This has come up a bunch of time now where we need some way to talk about different external modules. If we want to support multiple external modules, we also need to figure out if the user is required to parameterize them or we can parameterize them from the command line.
My general instinct is that this feature should mostly only be exposed for experiments and not a general language feature. Once again, attributes of some form would be really nice to be able to say: "we're doing something non-traditional here, please just hook into the right compiler machinery and support this behavior".
Separate from all this stuff, I think the simple solution of writing a parameterized main, not allowing any recursion, and throwing and error if the user does not provide values for all parameters is probably the right way to implement this feature.
Assuming that we should not be exposing this in general, how would this tie in with the gen configuration stuff? Should that be an exposed feature?
My worry with the "not allowing recursion" is that it seems like at least the default parameter case could lead to undefined behavior during compilation. The let bound case seems a little better there but still the user can instantiate main with no parameters (maybe on accident?) that would lead to some form of undefined behavior.
I thought about this a bit more and I've figured out how to add entrypoint binding information to the IR, which turned out to be a smaller (?) change than I thought it would be, so I might go with that for now...
During my work on this I realized this might be adjacently useful later as a way for filament
components to "act" like gen
components without actually hooking into the whole gen config thing; components could define some form of parameters that are "externally provided", and the code should be relatively easy to extend to that case. Not sure if this will ever be useful, but it could be cool to think about. I'm going to open an issue about this as well to formalize my ideas a bit.
Opened #441 !
Currently, in #439 I am adding the ability to provide parameters to the main component via a config toml file like so:
for a component like this:
There are a couple way's I've thought about doing this, but I am not sure which is easiest to implement/most robust.
Providing parameter defaults
This would (at the ast level) rewrite the component to look like
comp main[?E=8, ?M=23]
. This has a couple issues - default parameters aren't actually kept duringastconv
, as they are inserted in at the invocation level. Therefore, we would either have to rewrite this functionality or this method is sort of infeasible.Furthermore, if
main
is invoked recursively this might unintentionally hide errors about invalid instantiations of main - such as if we instantiatedmain[9]
, which shouldn't compile but will.Converting signature parameters to let-bound
Here, we again perform a transformation at the AST level to change
comp main[E, M]
to instead something like this:This also has issues if
main
is invoked recursively, as the parameters have been removed from the signature.Inserting the binding at the start of monomorphization
This is another possibility that is doable because the bindings are necessarily constant numbers. This has some more complexity, however, as name information is not necessarily retained in the IR stage, so we would have to figure out what
ParamIdx
the strings in the toml refer to, which would have to be done duringastconv
, and maybe we would have an extratop_level_binding
map insideContext
? This would not have any unexpected behavior though which is very nice.Dummy toplevel module
The final possibility is to add (at the AST level) a dummy component to invoke main:
This would once again be robust but would also require us to somehow copy all the timing information from main to toplevel, which I'm not sure is possible.