Code generation of environment values #1103
-
This is a question about the interaction of code generation and the global environment, in the presence of native .coalton files, and involves some degree of 'thinking aloud' -- I'd appreciate any feedback. A comment in typechecker/environment.lisp describes how the global environment is handled by the
expands to something like the following, trimmed for legibility:
The embedded constant struct values are dumped by the compiler to the output fasl. A functionally identical Coalton version might look like:
A question then arises: is it necessary or desirable to produce lisp source code that representing environment values? That is, given 'six.coalton', generate 'six.lisp' that looks like:
Are there alternatives? make-load-form in this case is bound to implementation-specific structures, in the form of the allocation and init forms returned by Perhaps expanding the question above: ought it always be possible to produce a functionally identical .lisp file from any given .coalton file? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I think the answer is "yes" since (re-)loading FASLs should be enough to allow later/further Coalton code to be type checked. A problem we were having before was that FASLs would get cached (without the env updates) by ASDF and when new Coalton code was loaded, old cached FASLs would be loaded, but the Coalton compiler wouldn't know anything, and lead to errors. We should be more rigorous with load form definitions. |
Beta Was this translation helpful? Give feedback.
I think the answer is "yes" since (re-)loading FASLs should be enough to allow later/further Coalton code to be type checked.
A problem we were having before was that FASLs would get cached (without the env updates) by ASDF and when new Coalton code was loaded, old cached FASLs would be loaded, but the Coalton compiler wouldn't know anything, and lead to errors.
We should be more rigorous with load form definitions.