($unported$ as suggested attribute to declare JS requirement) |
(aliens) |
||
| Line 6: | Line 6: | ||
IIFEs as an escape hatch are forbidden. (Only permitted in the shunting block and as a convenience for static assignments for legacy runtimes that don't support `class` and constant property additions to the prototype is too annoying.) |
IIFEs as an escape hatch are forbidden. (Only permitted in the shunting block and as a convenience for static assignments for legacy runtimes that don't support `class` and constant property additions to the prototype is too annoying.) |
||
'''2020 July 26''': I now think this should be the prescribed way for all languages. Consider McCarthy's first Lisp, or a demonstration of Guile in the Guix documentation for defining packages. I think these will be our "aliens" (cf Bracha). |
|||
Latest revision as of 15:55, 26 July 2020
The official way to interface with JS shall be `Function`.
Runtimes will be permitted to provide optional support for JS. Apps/modules that need JS compatibility will need an attribute to statically declare their requirement. ($unported$: true?)
You can ship a JS module (or module trees) by "compiling" the JS into a template literal, and then having a constructor that acts as a convenience wrapper around `Function`. However, this will be highly discouraged and is only made available as a stopgap so modules can eventually be ported to the triple script dialect.
IIFEs as an escape hatch are forbidden. (Only permitted in the shunting block and as a convenience for static assignments for legacy runtimes that don't support `class` and constant property additions to the prototype is too annoying.)
2020 July 26: I now think this should be the prescribed way for all languages. Consider McCarthy's first Lisp, or a demonstration of Guile in the Guix documentation for defining packages. I think these will be our "aliens" (cf Bracha).