> I don't agree with this. Two of us formalized, implemented, and tested > that paper in a month. That is hardly time-consuming, and it's not > very subtle since we have test suites to test our formalization.
I brought up your paper because it's good work. I wasn't criticizing it. But there's a difference between formalizing the operational core of a language and writing a language standard. BTW, only having two people work on it is an *advantage* -- committee work is hard. :) >> That includes more rigorous approaches like operational semantics > > Don't try to build a semantics for the entire language. Instead, build > a semantics for the "essentials" (i.e. objects and functions) and > write a function that elaborates all the details of language into the > semantics. a) I'm the one who advertised your paper, remember? b) You're arguing with a strawman. I'm not saying "operational semantics is hard! let's go shopping!" I'm saying that making things more precise and formal runs the risk of over-specification. Maybe these will becomes less of an issue if we decide to determinize more of the language (e.g. object enumeration). But I believe libraries will still be tricky. For example, I don't think the spec should ever provide an executable presentation of |Array.prototype.sort|, for example. Again, English can always swoop in and save the day. But at any rate, these are some of the challenges I'm talking about. c) This isn't the first time we've discussed a formally specified core + elaboration. We considered it back in the ES4 days. But the committee decided to go with something more traditional and moved towards a reference implementation. At the time, people complained that our choice of *ML* was too freaky and academic. (Now imagine selling a reduction semantics...) Doug has more recently suggested we use a subset of ES and write a meta-circular implementation, with the rationale that ES is more familiar and would be more approachable than ML. Semanticists prefer choosing the framework that most naturally expresses the semantics at hand. I'm certainly on board in principle. But I'm not really the one to convince. ;) d) If you're serious about suggesting lambda-JS as a basis (or starting point, anyway) for future editions of ECMA-262, may I make a suggestion? Do a proof-of-concept by taking the ES5 document and rewriting some of it in your suggested style. Not just the semantics but the document itself. It could be an illuminating exercise, and it would also likely result in a more compelling product. Nothing sells like concrete examples. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
