| 17:38 | <nicolo-ribaudo> | During the Module Harmony intersection semantics discussion, those of you who are championing/authoring proposals please feel free to jump in the discussion as if you were co-presenters when there are discussion about your proposal :) |
| 17:39 | <nicolo-ribaudo> | ( Luca Casonato Kris Kowal guybedford caridy ) |
| 18:38 | <littledan> | Kris Kowal: I don't understand your comment; I thought this presentation is the epic |
| 18:38 | <littledan> | but yeah the presentation would be reworked and written down in other places maybe if that'd help |
| 18:39 | <Kris Kowal> | I’ll clarify that my comment is about organizing repositories. |
| 18:42 | <shu> | here's the one-sentence question form of my concern: how hard will it be for an implementer who's not going to any of the module harmony calls to design and implement one of these features? |
| 18:44 | <littledan> | here's the one-sentence question form of my concern: how hard will it be for an implementer who's not going to any of the module harmony calls to design and implement one of these features? |
| 18:44 | <littledan> | the idea is to document things |
| 18:44 | <nicolo-ribaudo> | here's the one-sentence question form of my concern: how hard will it be for an implementer who's not going to any of the module harmony calls to design and implement one of these features? I can speak for module expresions/declarations. Other proposals (i.e. the various compartments layers) do a better job with regard to this |
| 18:44 | <littledan> | (as Kris said) |
| 18:45 | <shu> | Do you have any concrete source of concern that it'd be harder for modules than other proposals? |
| 18:49 | <nicolo-ribaudo> | Do you know how much this division follows the 262-HTML division? I'm sure things got mixed up with the hooks refactor we landed some months ago, but did the previous spec layering match the implementation layering? |
| 18:52 | <shu> | nicolo-ribaudo: sorry, i don't currently, would need to do research |
| 18:56 | <Kris Kowal> | I think the word we’re looking for is foreshadowing. Each individual proposal should have notes on mechanisms that foreshadow later proposals. |
| 19:46 | <nicolo-ribaudo> | import source from from; 👀 |
| 19:46 | <nicolo-ribaudo> | (in practice no one would use from there and the ambiguity is solved by a two-tokens-lookahead) |
| 19:57 | <ljharb> | fwiw, wrt alternatives, i would not be happy with increasing the asymmetry between static and dynamic, compared to the current spec (reacting to some of the suggested alternatives) |
| 19:59 | <Kris Kowal> | I am in favor of parity in general between static and dynamic import. |
| 19:59 | <littledan> | Are these significantly different in terms of their asymmetry? I haven't heard anyone advocate for import.source foo from bar but certainly it'd be easier to parse |
| 19:59 | <ljharb> | (lol also, import.phase source foo from 'path' is an alternative that would work for import.phase() because dynamic import is syntax not a function reference) |
| 19:59 | <Kris Kowal> | The only distinction should ever be static discoverability. |
| 19:59 | <ljharb> | or import.source i suppose, sure |