The experiments/stasm/spec proposal #218
stasm
started this conversation in
Show and tell
Replies: 1 comment
-
|
The slides from my yesterday's presentation on this: MaybeFormat 2.0. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Similar to @eemeli's #216, I've tried to put together a holistic proposal for my vision of what MessageFormat 2.0 could be. I'm starting a new discussion thread to collect written feedback on it. Please find it at:
The proposal is intentionally more limited in scope and somewhat more limited in power than Eemeli's. In previous discussions I frequently brought up simplicity, and the call for proposals gave me an opportunity to refine and narrow down what I mean by that. See the proposal's README for a few more thoughts on this.
I tried to avoid shortcuts and special cases, although I'm sure there are many things still in my proposal that could be made less complex. If I kept it in, it's most likely because it solved some other issue which in my opinion was more significant, or which in my opinion helped avoid complexity for some other reason. Ultimately, I'm sure I made a few subjective decisions. I'm looking forward to discussing about many of these decisions, and in particular, how one decision can influence other decisions.
One crucial part of the proposal is the stub specification of the function registry. We talked about the registry many times, but at least for me it was always somewhat vague in terms of how it could look like, what it could do, and what it could be used for. One interesting observation from preparing the proposal was that perhaps we can achieve many of our goals through the registry (and custom functions), rather than messages and expression inside them. Indeed, it seems that just by calling custom functions with a single operand and a map of options, and by matching the output of these functions against variant keys, it's possible to build interesting and powerful interactions.
My goal when I started documenting this proposal was to define the lower bound on the complexity of MessageFormat 2.0. As the WG, we might not want to proceed with this proposal, but I hope that at least we will have seen how little we actually need to achieve the WG's goals and enable more expressiveness in software translation. Every feature we add on top of that should be carefully scrutinized to make sure it's worth the added complexity.
Beta Was this translation helpful? Give feedback.
All reactions