Re: Better sketch of a minimally invasive module system

#1

I’d like to open discussions related to @markm’s Better sketch of a minimally invasive module system post here.

1 Like
#2

Now that there are tenable concerns raised, I personally feel that urge to model those concerns in my corner to better digest (and validate) underlying semantics-preserving and cost-aversion mechanism/assumptions from a more concrete position. (I should be back to SES time next week, so I won’t get to that before tomorrow’s meeting)

Cliff-notes:

  • Dynamic imports — my (imaginary) rewriter would replace with $import(…) (slightly different from for eval eval($sanitize(…)))

  • Top-level await — my (current) model shows that it is very straightforward to model (but it landing in the spec is where my doubts live).

    I think that anything short of meta-property methods with resolvable arguments will result in circular deadlocks that may not be visible to the authors to reason about, but if instead the author was forced to write import.await(importedA, importedB) to force resolution before top execution and/or export.await(… resolvables) then top-level await being spec is a palatable addition.