expands to something like the following, trimmed for legibility:
\n(let ((env coalton-impl/entry:*global-environment*))\n (setf env\n (coalton-impl/typechecker/environment:set-value-type\n env 'i 'integer))\n (setf env\n (coalton-impl/typechecker/environment:set-name\n env 'i\n '#s(coalton-impl/typechecker/environment:name-entry\n :name i\n :type :value\n :docstring nil\n :location \"coalton-toplevel (nil)\")))\n (setf env\n (coalton-impl/typechecker/environment:set-code\n env 'i\n '#s(coalton-impl/codegen/ast:node-direct-application\n :type integer\n :rator-type (integer → integer)\n :rator coalton-library/math/num::|instance/num integer-coalton-library/classes:fromint|\n :rands (#s(coalton-impl/codegen/ast:node-literal\n :type integer\n :value 6)))))\n (setf coalton-impl/entry:*global-environment*\n env))\n\n(coalton-impl/global-lexical:define-global-lexical i integer)\n\n(setf i\n (coalton-library/math/num::|instance/num integer-coalton-library/classes:fromint|\n 6))\n\n(setf (documentation 'i 'variable)\n \"i :: integer\")\nThe embedded constant struct values are dumped by the compiler to the output fasl.
\nA functionally identical Coalton version might look like:
\n(package six)\n\n(define i 6)\nA 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:
\n;; Generated from tests/test.coalton Tue May 7 19:53:19 UTC 2024\n\n(eval-when (:load-toplevel)\n (unless (eq (coalton-impl/settings:coalton-release-p) nil)\n (error \"~A was compiled in development mode but loaded in release.\" nil)))\n\n(defpackage #:six\n (:use #:coalton))\n\n(in-package #:six)\n\n;; set-value-type i\n\n(global-env:set-value-type! 'i\n (... source form that evaluates to an instance of ty-scheme with value 'coalton:integer, like:\n (make-ty-scheme ...))\n\n;; set-name i\n\n(global-env:set-name! 'i\n (... evaluates to coalton-impl/typechecker/environment:name-entry))\n\n;; set-code i\n\n(global-env:set-code! 'i\n (... evaluates to coalton-impl/codegen/ast:node-direct-application))\n\n(declaim (sb-ext:muffle-conditions sb-kernel:redefinition-warning))\n\n(coalton-impl/global-lexical:define-global-lexical six::i integer)\n\n(setf six::i\n (coalton-library/math/num::|INSTANCE/NUM INTEGER-COALTON-LIBRARY/CLASSES:FROMINT|\n 6))\n\n(setf (documentation 'six::i 'variable) \"I :: INTEGER\")\n\n(declaim (sb-ext:unmuffle-conditions sb-kernel:redefinition-warning))\nAre 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 make-load-form-saving-slots, and I didn't see a way to adapt those that wasn't sbcl-specific. Adding a new generic (\"make-source-form\") has proven to work, for the most part, but maybe there is a different approach.
Perhaps expanding the question above: ought it always be possible to produce a functionally identical .lisp file from any given .coalton file?
","upvoteCount":2,"answerCount":1,"acceptedAnswer":{"@type":"Answer","text":"I think the answer is \"yes\" since (re-)loading FASLs should be enough to allow later/further Coalton code to be type checked.
\nA 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.
\nWe should be more rigorous with load form definitions.
","upvoteCount":1,"url":"https://github.com/coalton-lang/coalton/discussions/1103#discussioncomment-9356827"}}}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.