Parameterized Evaluators

[Bradley Farias]

Much like import assertions is a generic mechanism. I could imagine non-WASM evaluators and parameterization of them:

import './model.json' assert { 
  type: 'json'
} as {
  evaluator: 'json-schema', schema: 'https://schema.org/...'
};

Unlike assertions I do think having evaluatior (bikeshed) be a shorthand is fine since it defines what is being parameterized and I cannot think of a reason to drop it ever even if it is always implicitly defined.

[Guy Bedford]

Thanks for putting thought to these variations. Yes, where we currently do import WasmModule from 'wasm-module'; WebAssembly.instantiate(...) that is effectively doing parameterization but moving all the parameters to dynamic JS.

The benefit of JS programmatic parameterization is that you get runtime validations, dynamic generation etc more easily than if we try and reconstruct these features in a declarative form that eg might only permit primitive parameters and have more limited control.

For example, the use case you describe could be reflected in JS:

import { parseWithSchema } from './module.json' assert { type: 'json' } as 'scheme-generator';

export default await parseWithSchema('https://schema.org/...');

So the question is how much to make declarative versus programmatic reflection here, and throwing examples at that question seems to me like a good way to tackle it.

[Bradley Farias]

The problem with dynamic evaluators is ahead of time tooling can't use it easily and likely won't have guarantees about parameters being stateful. I think we don't need to decide on if we want declarative parameterization but would like to ensure we can add it later and it is called out as possible to do as a follow on.

[Luca Casonato]

Not relevant to the refocused scope of this proposal. Please move any concerns about the import attributes module bag to that proposal, or the TC39 Discourse.