On Jul 14, 2011, at 12:00 AM, Luke Hoban wrote: > > I don't want to quibble about philosophical pedantry, but that's really all I > mean by my shyness about General Principles. They're strictly *harder* to > decide on than the problem at hand. It's too easy to lose focus and waste > time arguing abstractions. And then even when we agree on general principles, > when we get into concrete situations it's too easy to start quibbling about > exactly how to interpret and apply the principles for the problem at hand. > > I prefer to work out from the middle of the maze, learning and refining > principles as I go, rather than trying to decide on them all up front. > > Agreed. The principle itself is not really the primary point. But I do > think there is a fairly crisp line that can be drawn at the level of “any > observable behaviour of an object that can be created with extended code can > also be provided by an object created without using extended code”. > Ultimately though, the goal is just to provide the most value to the most > users.
We could add some requirements to http://wiki.ecmascript.org/doku.php?id=harmony:harmony. We already have this first bullet from "Means": Minimize the additional semantic state needed beyond ES5. Perhaps this should be an end in itself, but I don't think so -- not as stated. We serve the users, which may require new (minimized) semantic state, even if on the inside of the observable boundary (e.g., generators, yield). To your point, if there are shared-heap-exposed new semantics that would surprise old script, that would be bad, but not strictly verboten in my view -- not the end of the world. We've had "unusual" host objects in various browsers (notably IE) for a long time. But there's novel and then there is crazy. Here's an example of crazy: were we to add call/cc to ES.something, an old script could lose its invariants by innocently calling a new function via the shared heap, where the new function captures the full continuation, returns to the event loop, and much later calls the continuation. This is one reason we won't add call/cc (the other is that implementors would have to capture native activations, to preserve functional abstraction over self-hosted vs. embedding-native-code-hosted implementation, and that raises the bar, risking some defecting, harming interoperation). If you want to propose some changes to http://wiki.ecmascript.org/doku.php?id=harmony:harmony please let me know. We could waste a lot of time on abstract principles, but any more concrete and crisp fixes or additions are welcome. /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
