(JS support is optional, it must be statically declared, and actual use is discouraged) |
(aliens) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
The official way to interface with JS shall be `Function`. |
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. |
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. (<code>[[$unported$]]: true</code>?) |
||
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. |
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.) |
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).