Re: Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
I guess it's one of these things we may try and static-analyze-away. Cheers, David P.S.: Should I mention OCaml's option types or Haskell's maybes at this point ? On Thu, 2007-11-15 at 14:06 -0800, Graydon Hoare wrote: P T Withington wrote: I must say, coming from Dylan, es3's undefined _and_ null seem like overkill... but we're stuck with them now! I think they feel like overkill to everyone, but yeah. Backward compatibility! -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
Various interested parties favored something like the json2.js API already, and I think everyone will rally round it and beat on it, to make sure it has the right usability and knobs. I'm hopeful. +1 from me. One request: When a filter function is provided to JSON.parse, I would like the filter to be called with |this| defined to be the root object that is being created by the parsed JSON text. Having a reference to the created root object can be useful for some forms of filters such as reference resolvers. The problem in general is that Bob's classes and Alice's classes were written without anticipating Carol's combination of the two, but Carol cannot use MI. Nor can she provide objects that match structural types. She has to inherit from both Bob's and Alice's classes. Was multiple inheritance discussed for inclusion in ES4? I am aware of the general arguments against it, but I was wondering if had been considered or if there are technical aspects of ES4 that preclude it. Does this clear things up? Yes, that certainly helps me to understand the rationale. Thanks for being so willing to answer questions about ES4 issues. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
On Nov 15, 2007, at 9:17 AM, Kris Zyp wrote: +1 from me. One request: When a filter function is provided to JSON.parse, I would like the filter to be called with |this| defined to be the root object that is being created by the parsed JSON text. Having a reference to the created root object can be useful for some forms of filters such as reference resolvers. Interesting -- a short example would help sell this, I bet. The problem in general is that Bob's classes and Alice's classes were written without anticipating Carol's combination of the two, but Carol cannot use MI. Nor can she provide objects that match structural types. She has to inherit from both Bob's and Alice's classes. Was multiple inheritance discussed for inclusion in ES4? I am aware of the general arguments against it, but I was wondering if had been considered or if there are technical aspects of ES4 that preclude it. We passed over MI without any regrets, for the general reasons you give. Also, even with MI, classes are not as flexible as structural types, as I've pointed out. They're different beasts, with different as well as some overlapping use-cases from structural types. Does this clear things up? Yes, that certainly helps me to understand the rationale. Thanks for being so willing to answer questions about ES4 issues. No problem. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
On Nov 14, 2007, at 5:34 PM, Brendan Eich wrote: On Nov 14, 2007, at 2:03 PM, Maciej Stachowiak wrote: Conversions: In addition, any value in the language converts to a member of AnyBoolean, but the conversions specified are all to the more specific boolean type, so perhaps it should be expressed that way to avoid confusion. I thought this too, when reviewing this section. I think this is an open issue, but I can't find a ticket for it. Found thanks to Lars: http://bugs.ecmascript.org/ticket/246 /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
On Nov 14, 2007, at 11:56 PM, Brendan Eich wrote: Modula 3 had branding for making nominal types from structural types, but going the other way, unbranding a nominal type to get a structural type, has no precedent I know of, Shaver pointed to generic metaprogramming using C++ templates, which is close -- but of course the C++ static type system must make sense of everything before runtime, and you can't forge an instance of a C+ + class. Important safety tip! /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
On 2007-11-14, at 19:22 EST, Graydon Hoare wrote: (As far as I can tell -- not being a dylan hacker -- dylan doesn't even go as far as having a global sentinel type like nil) The Dylan equivalent of a nullable type is a union of your type with a singleton that acts as the sentinel. Most often a singleton of the boolean false value is used. So there is a macro `false-or(type)` that expands to `type-union(type, singleton(#f))`. This works for any type other than a nullable boolean. Because any value other than #f coerces to true in a boolean context, #f is very similar to nil. I've never known anyone to need a nullable boolean. (Although I have seen whacky es3 code that uses true/false/null as a sloppy 3-valued enumeration -- with attended bug reports when null is passed expecting it to behave like false.) I must say, coming from Dylan, es3's undefined _and_ null seem like overkill... but we're stuck with them now! ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
On 14/11/2007, Maciej Stachowiak [EMAIL PROTECTED] wrote: Section III. Syntax: The new non-contextual keywords, and the resulting need to specify dialect out of band, are a problem. I'll have more to say about compatibility under separate cover. The model with version and e4x arguments in the Content-Type for changing JS parsing has been used by moz already. Can we hear their experience with regard to this compatibility problem? Generally I think opt-in versioning such as this is the best you can get for compatibility. Perhaps it would be wise to have a method that is not external to the script as well, though, but I fail to see how that could work compatibly in current ES3 only implementations. - The RegExp change - is this really a bug fix? It's likely that this is not a big compatibility issue (Safari's ES3 implementation had things the proposed ES4 way for some time) but I think ES3's approach may be more performance and generating a new object every time does not seem especially helpful. It's a SpiderMonkey+ES3 fix, as I recall. The main problem with the ES3 spec is that developers don't expect lastIndex to persist when they evaluate the literal a second time, but also other mutable properties. Real world code breaks because of this. Is there any significant implementation that anyone would claim is 100% free of ECMAScript 3 compliance bugs? I don't even think you would get 100% compliance if you counted all engines taken together - I think there's issues where no engine really gets it right, or for that matter can afford to get it right. At least, no browser hosted engine. Section IV. Classes: If any of the new type system is worthwhile, surely this is. The impedance mismatch between the class model used by most OO languages and by specifications like the DOM, and ES3's prototype model, is needlessly confusing to authors. So I approve of adding classes in a reasonable and tasteful way. somewhat offtopic For compatibility reasons with the ES3 bindings for the DOM, I think the train has already left with regards crafting the DOM bindings fully into the ES4 model. The way the ES bindings work is incompatible with both ES3 prototype object hierarchies and ES4 classes/interfaces. In particular we have multiple parallel interfaces, each of which developers expect to be an object inherited from using the prototype scheme. The bindings are incompatible with regards to ES4 interfaces and classes in that ES4 interfaces from what I understand don't carry implementation, aren't runtime objects nor can they present prototype objects (obviously, since they aren't runtime objects). I can only see two ways to solve this problem: - Add a multiple inheritance scheme to ES4 that works on the prototype delegation system as well as the nominal type system, solving the diamond problem*. -- Severely complicating the object system. - Remove these multiple parallel interfaces being exposed as run time objects from the ES bindings, allowing a single inheritance hierarchy to be formed from implementing them using ES4 interfaces. -- Making a conformant DOM.next implementation not be a conformant DOM.current implementation. * A good resolution mechanism solving the diamond problem can be found in Python and was borrowed by Perl 6, IIRC. /somewhat offtopic Literals: - I am surprised to see a decimal type (a type that is not directly supported in current mainstream hardware) even though generally popular types like single-precision IEEE floating point and 64 bit integers are not present. I guess it directly addresses one large real world problem - that fifths are inexactly represented in doubles, and there is a large demand for reliable number handling of decimal values for amongst other things money and measurements. I doubt the demand for single floats or 64-bit integers is even close to as large as the demand for accurate handling of common real world values like money. Section V. Record and array types: Structural types are confusingly similar to yet different from classes. Mostly they offer a subset of class functionality (though reading ahead I did see a few features limited to them). They do allow for orthogonal type ideas, and I think many ES3 developers will be more comfortable with structural types than with classes and interfaces, because they can add contracts without changing their coding style. Replacing code written for the ES3 system of using closures for privacy and prototypes for inheritance with code written for the ES4 classical inheritance system will require considerably more rethinking one's implementation. Also, already having prototype-based objects and class-based objects it seems excessive to add yet a third way. I recommend removing them and adding any features that are sorely missed as a result to classes. Well, structural types doesn't really affect the object types, do they? AIUI structural types are part of the contract system, not the inheritance
Close review of Language Overview whitepaper
Hello ES4 fans, I have now read the recently posted whitepaper. I marked up my printed copy with many comments in the margins, and I am sharing them with the list now. Please note that this does not constitute an official Apple position, just some personal off-the-cuff opinions. I have discussed the proposal with some of my colleagues, including Geoff Garen who attended the recent f2f, but we have not figured out a consensus overall position or anything. With the disclaimers out of the way, here are my review comments: Section I. Goals: I strongly agree with the stated goals of compatibility and enabling large software development. I wonder if perhaps performance should be added as a goal. At the very least we want it to be possible to achieve performance on par with ES3 engines, and ideally we want to enable better performance. Section II. Programming in the small: ... make the writing and reading of fragments of code simpler and more effortless. That is somewhat dubious gramatically, I suggest (with additional style fixes) make the reading and writing of code fragments easier. Portability: This section first it says that the full language must be supported - subset profiles are not desirable. Then it says that, to allow ES4 to be practically implementable on small devices and in hosted environments, certain features, like extensive compile-time analysis and stack marks cannot be part of the language. Then it says those features are part of the language, but optional. I hope the problems here are clear: first, the section plainly contradicts itself. It argues against subsets and certain classes of features, and then says the spec includes such features as optional, thus defining a subset. So that needs to be fixed in the whitepaper. More significantly, I think this may be an indication that the language has failed to meet its design goals. My suggestion would be to remove all optional features (though I could be convinced that strict mode is a special case). Section III. Syntax: The new non-contextual keywords, and the resulting need to specify dialect out of band, are a problem. I'll have more to say about compatibility under separate cover. Behavior: - This section has says that variation among ES3 implementations entails a license to specify behavior more precisely for ES4. However, the example given is a case where behavior among two implementations was already the same, due to compatibility considerations. I actually think both convergence on a single behavior where variation is allowed, and variation that leads to practical compatibility issues are license to spec more precisely, - The RegExp change - is this really a bug fix? It's likely that this is not a big compatibility issue (Safari's ES3 implementation had things the proposed ES4 way for some time) but I think ES3's approach may be more performance and generating a new object every time does not seem especially helpful. Impact: This section talks a lot about incompatibilities between ES4 and ES3, however I think incompatibilities with ES3 as specced are in themselves almost irrelevant. What matters is incompatibilities with existing implementations and the content that depends on them. This section also appears to talk disparagingly about some implementations prioritizing compatibility over ES3 compliance, implies that any deviations may be due to inadequate engineering practices, and implies that only some implementations are not compatible with ES3. Is there any significant implementation that anyone would claim is 100% free of ECMAScript 3 compliance bugs? I doubt it, and so I think we should make this section less judgmental in tone. The web: Here especially, the actual concern is real-world compatibility, not compatibility with the ES4 spec. Furthermore, it completely ignores forward compatibility (the ability to serve ES4 to older browsers that do not support it). It implies that this is just an issue of aligning the timing of implementations. Ignoring for the moment how impractical it is to expect multiple implementations to roll out major new features in tandem, I note that there were similar theories behind XHTML, XSL, XHTML 2, and many other technologies that have largely failed to replace their predecessors. Again, I'll say more about compatibility (and in particular how the WHATWG approach to compatibility can be applied to ES4) under separate cover. Section IV. Classes: If any of the new type system is worthwhile, surely this is. The impedance mismatch between the class model used by most OO languages and by specifications like the DOM, and ES3's prototype model, is needlessly confusing to authors. So I approve of adding classes in a reasonable and tasteful way. Dynamic properties: the fact that the dynamic behavior is not inherited makes class inheritence violate the Liskov
Re: Close review of Language Overview whitepaper
On Nov 14, 2007 2:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Nullability: Are non-nullable types really worth it? I am not sure. Does any other explicit type system for a dynamic OO language have such a concept? The whitepaper says that the ability to store null is occasionally the source of run-time errors but will not dynamic- checking result in runtime errors anyway when assigning null to a non- nullable variable (except in strict mode)? That was one of the features I most liked. Working in Flex, I have problems with nullable variables all the time. Map: Long overdue to have a real hashtable type. Yes! Parameterized types in general are probably my favorite addition. (Now if only there were some sort of solution comparable to abstract classes) -- T. Michael Keesey Director of Technology Exopolis, Inc. 2894 Rowena Avenue Ste. B Los Angeles, California 90039 http://exopolis.com/ -- http://3lbmonkeybrain.blogspot.com/ ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
Hey Maciej, thanks for the detailed comments. As many detailed responses as I can muster below -- all opinions mine unless noted (e.g. where I cite a group opinion). On Nov 14, 2007, at 2:03 PM, Maciej Stachowiak wrote: Goals: I strongly agree with the stated goals of compatibility and enabling large software development. I wonder if perhaps performance should be added as a goal. At the very least we want it to be possible to achieve performance on par with ES3 engines, and ideally we want to enable better performance. I know of proofs that much better performance (order of magnitude over latest interpreters) is coming to JS1 implementations, so I think this is a red herring. It would be good to avoid anti- performance mandatory changes, of course -- that might not be obvious. Programming in the small: ... make the writing and reading of fragments of code simpler and more effortless. That is somewhat dubious gramatically, English crit, watch out! ;-) I did not write this, but I'll leap to the author's defense. The grammar's fine and usage manuals (Partridge, Fowler -- if memory serves) allow more effortless. See also http://www.google.com/search?hl=enclient=firefox-arls=org.mozilla% 3Aen-US%3Aofficialhs=CGSq=%22more+effortless%22+English +usagebtnG=Search First hit: http://www.bartleby.com/227/0206.html I suggest (with additional style fixes) make the reading and writing of code fragments easier. I like your suggestion, though. Portability: This section first it says that the full language must be supported - subset profiles are not desirable. Then it says that, to allow ES4 to be practically implementable on small devices and in hosted environments, certain features, like extensive compile-time analysis and stack marks cannot be part of the language. Then it says those features are part of the language, but optional. Clearly the overview should distinguish between mandatory standard mode features and optional strict mode and reflection features. But you have a point about optional reflection features being useless on the web, so what's the point? One answer is to have a normative spec, so where support exists, the implementations can interoperate. This may not be enough for reflection -- it depends on likely uptake. We think it is enough to justify strict mode. More below. Syntax: The new non-contextual keywords, and the resulting need to specify dialect out of band, are a problem. I'll have more to say about compatibility under separate cover. We've talked about this before, and I'm looking forward to your thoughts. I would hope we can avoid having to do what we believe should be post- ES4 standardized AST, reader, and even macro work, just to allay concerns about ES4-ES5. We can't do all that work before ES4, but of course we want to make next time better. I noted on IRC that adding the 'x' flag to regexps, and codifying how IE handles / in a character class in a regexp (which browsers have had to follow), both break by-the-book ES3 scanners. Behavior: - This section has says that variation among ES3 implementations entails a license to specify behavior more precisely for ES4. However, the example given is a case where behavior among two implementations was already the same, due to compatibility considerations. I actually think both convergence on a single behavior where variation is allowed, and variation that leads to practical compatibility issues are license to spec more precisely, We do not want to overspecify, however. The majority of those who've expressed an opinion in TG1 do not want, e.g., to specify Date.parse as it is implemented in any given browser, never mind finding the intersection among all browsers. - The RegExp change - is this really a bug fix? It's likely that this is not a big compatibility issue (Safari's ES3 implementation had things the proposed ES4 way for some time) but I think ES3's approach may be more performance and generating a new object every time does not seem especially helpful. This bug is the second most duplicated among bugs filed with mozilla.org's bug system since 1998: http://bugzilla.mozilla.org/show_bug.cgi?id=98409 Full dup-count available at https://bugzilla.mozilla.org/duplicates.cgi? sortby=componentmaxrows=1000changedsince=3600product=Core sort by Component for best results. This singleton pigeon-hole problem hurts users all the time (I get mail from individual developers confused by it, at least once a year). The performance worry for the proposed ES4 fix of evaluating a regexp literal to a new object, just as is done for other mutable objects expressed literally, is not an issue in our experience. Just as the compiler precomputes invariant parts of function objects, so it can memoize regexp constant parts, and wrap a mutable object around the shared immutable innards on each evaluation. Quality implementations do this for function
Re: Close review of Language Overview whitepaper
JSON: Sounds good. This proposal is withdrawn and another API is being considered for reinclusion later. See http:;//json.org/json2.js. toJSONString and parseJSON are going away? I was actually wanting to write and suggest the removal of these, with Douglas's recent change in his JSON API. I am glad to see these will be going away. Will ES4 include the other API (JSON.parseJSON / JSON.stringify)? You miss the main difference: structural types are not equated by name, so they avoid the inheritance trap of classes, which consists I would love to understand the purpose of structural types better. I don't understand how base class evolution is constrained in ways that super record types aren't. I also don't understand how the goal of applying types to existing ES3 objects can not be achieved with wrap operator and nominal types. I know there something I am missing here. Thanks, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
