Should we even have profiles

[fgmccabe]

Allowing different flavors of what engines can support risks long term fracturing of the wasm ecosystem.

In addition, from the pov of an engine provider, they will be under long term pressure to keep up to date with the whole of the specification. That is in their interest because it enhances the probability that their engine will be useful.

From the pov of a wasm module developer, they will be motivated to go for the greatest common denominator: i.e., they will generate code that runs on as many engines as possible.

However, there is a similar but different issue that we should address - the consequences of having Wasm be a 'living document'. That implies that any given engine will likely be behind the current standard to varying extents.

[rossberg]

I believe this very question is already addressed in the overview. That different ecosystems will have different constraints and some simply won't be able to support everything is a fact of life. For example, it is a safe bet that block chains will never allow non-determinism, or that certain embedded systems will never support GC.

In reaction to this, the purpose of this proposal is not to increase fragmentation, but the opposite: to reduce it! Namely, by at least specifying a few well-defined subsets that different such ecosystems can agree upon to the largest degree possible – as opposed to everybody inventing their own, slightly different custom subsemantics.

I agree that language evolution is a different problem, and it's explicitly called out as a non-goal for this proposal.

[titzer]

I agree with Andreas in that profiles are important to define a blessed subset of Wasm that is suitable for a domain. For example, embedded systems that are based on CPUs without SIMD support would benefit from a profile definition that excludes it. However I also agree with Francis about the "living document" problem. I think we need a more permanent way to nail down a specification version number. It might be as simple as tagging it with a year.

…

On Wed, Oct 27, 2021 at 2:44 PM Andreas Rossberg ***@***.***> wrote: I believe this very question is already addressed in the overview. That different ecosystems will have different constraints and some simply won't be able to support everything is a fact of life. For example, it is a safe bet that block chains will never allow non-determinism, or that certain embedded systems will never support GC. In reaction to this, the purpose of this proposal is not to increase fragmentation, but the opposite: to *reduce* it! Namely, by at least specifying some well-defined subsets that different such ecosystems can agree upon to the largest degree possible – as opposed to everybody inventing their own, slightly different custom subsemantics. I agree that language evolution is a different problem, and it's explicitly called out as a non-goal for this proposal. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC46VVH433TRDRLVL3FCTLDUJBJBTANCNFSM5G2ZNUIQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rossberg]

#3 has more discussion of this question.