Re: Is ES3 good enough? Was incrementally strengthening ES3 paradigms considered?
On 2007-11-14, at 00:14 EST, Yuh-Ruey Chen wrote: Oh come on :) I was referring to the syntax of the class system, which is undoubtedly Java-esque. Lot of Java haters in the functional (no 1st-class functions!) and scripting (too verbose!) programming crowd. Pretty much everyone's first impression of the class system in ES4 is that Java is being merged into the language. Kinda like how everyone thinks that Java inherited its type system from C++ instead of Modula-3. A key difference from Java is that types are optional. There is not enough experience with es4 yet to know, but in other type-optional languages I have worked with, I did not have a Java-esque feeling of verbosity. Perhaps this is because I was coming from a dynamically- typed background, so I did not have the reaction that given types I had to declare them everywhere. Someone coming from a statically- typed background might just continue their old habits and never discover the freedom and power of leaving out unnecessary declarations. In my experience with Dylan, it worked best to only specify types to enforce contracts and to dispatch generic functions. In particular, you almost never declared the types of local variables, the compiler would work that out for you. Ideally, a type-inferencing compiler should be able to warn you when the lack of a type declaration will cause a run-time type check (safety warning) or run-time dispatch (performance warning). ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
like and is like
After searching through the wiki and ecmascript.org site, I still can't see any formal or informal explanation of how like and is like work, except in passing, and not with precision. Does this information exist somewhere? Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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: generic function with structural types questions
By fixed, do you mean an RI bug or a spec issue? If it's just an RI
bug, can you tell me what those exprs are supposed to evaluate to?
-Yuh-Ruey Chen
Lars T Hansen wrote:
At present, generic functions do not discriminate on structural types.
This probably needs to be fixed, but I've not looked into it.
--lars
On 11/12/07, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
Given the following definitions:
class C {var p: int};
type S1 = {p: int};
type S2 = {p: int, p2: double};
generic function foo(x);
generic function foo(x: *) 0
generic function foo(x: C) 1
generic function foo(x: S1) 2
generic function foo(x: S2) 3
generic function foo(x: like S1) 4
generic function foo(x: like S2) 5
var o1: C = new C();
var o2: S1 = {p: 10};
var o3: S2 = {p: 10, p2: 3.14};
var o4 = {p: 10};
var o5 = {p: 10, p2: 3.14};
var o6 = {p: 10, p2: 3.14, p3: hi};
What do the following exprs evaluate to?
foo(o1);
foo(o2);
foo(o3);
foo(o4);
foo(o5);
foo(o6);
Also, I know that S1 : Object, but is S2 : S1? I've looked at
http://wiki.ecmascript.org/doku.php?id=clarification:type_system and
it's not clear to me. Is it still true that C : S1?
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: need some clarification on compile-time type vs. run-time type
On Nov 13, 2007, at 10:40 PM, Yuh-Ruey Chen wrote:
I don't see how that's workable. I mean, technically it is, since |is|
is a runtime check. But it creates another incompatibility between
type annotations and |is|, and you seem pretty adamant to keep the two
as coherent as possible.
You're right, there are problems with unifying type and value
expressions, giving type expressions priority. There may even be
problems with just type expression syntax as proposed, see http://
bugs.ecmascript.org/ticket/309.
d) x instanceof function(p: int): int {} // syntax error?
Oh, I see -- on second thought I meant nothing like allowing (d) --
sorry. instanceof only takes a value expression on its right, but if
that evaluates to a type meta-object, it does something sane and
instance-ofish.
So I take that |x instanceof {p: int}| won't work, and we'd have to
use
|T = type {p: int}; x instanceof T| instead?
No, the restriction on instanceof comes from ES3, which introduced
it, along with object initialisers. So x instanceof {p:int} (given a
binding for 'int' of course) is perfectly valid ES3 and ES4. It
throws an error in ES3 implementations that do not reserve
'int' (e.g. SpiderMonkey):
js int = function (){}
function () {
}
js x = 42
42
js x instanceof {p:int}
typein:3: TypeError: invalid 'instanceof' operand ({p:(function () {})})
I truly doubt there is any code out there with (d). It's a backwards
incompatibility I'd be willing to break. If there is code out there
with
this, well, the new syntax error should tell them that they're doing
something really stupid.
You're no doubt right, but why mess with instanceof to take a type
expression on the right? We still have to work out type expression
grammar as it intrudes into value expressions to everyone's
satisfaction. I'd rather keep instanceof's right operand a value
expression and fry other fish.
Plenty of discussion going on in ticket 300 concerning this. Ugh, this
semi-merging of value and type exprs is getting awkward. We're
ending up
with just as many gotchas as we had before at this rate.
Yes, this merge attempt failed already -- it was doomed from the
start. We need to get type expressions by themselves working. I'm
pretty sure we can resolve all grammatical issues to-do with type
expressions, and in that event, allowing a runtime name instead of
insisting only on a fixed type name will be easy.
Alright, overview time again. Our current goals are:
1) Make |is| less restrictive and allow it accept (some) value exprs.
At this point (some) means name expressions, not restricted to be
fixed type names.
2) Keep |is| and type annotations coherent.
Check, but allowing arbitrary names in type annotations is out. Still
coherent enough. Call it compromise, if you must -- I think 'is' the
operator has to compromise because it has too many connotations, and
different use-cases from type annotations.
3) Keep |is| and |instanceof| (somewhat) coherent.
We should define coherence more precisely:
* 'is' takes a type expression on the right, but allows runtime name
in addition to fixed type name.
* instanceof takes a value expression per ES3 but if its result lacks
a [[HasInstance]] internal method (new formalism for ES4 needed, I'm
using ES3 meta-methods here), it checks for a meta-object result and
does 'is' -- else it throws TypeError.
4) Keep all the type operators coherent (to a certain extent).
Let's see:
* 'cast' requires a fixed type expression on the right (no variable
name)
* 'wrap' and 'like' require fixed type expressions.
5) Try not to introduce too many exceptions to the rule a.k.a.
gotchas.
Yup.
Whatever we do to advance one goal, another goal becomes more
compromised. Maybe we can place priorities on these goals? If we can
abandon one or two of these in favor of the other goals, this job
would
be much simpler. Need to think on this some more...
Let me know what you think of my interpretations and elaborations
just above. Thanks,
/be
___
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: Restricted Eval
On Nov 1, 2007 3:46 PM, Kris Zyp [EMAIL PROTECTED] wrote:
It's a sandbox, right? Should be safe. Not so fast:
last they gave up. rexec was removed from the language.
With the complexity of creating and verifing a sandboxing eval that allows
shared mutable objects with some degree of safety, is it conceivable that
ES4 could alternately pursue sandboxed eval through a shared nothing
construct? I remember that Brendan mentioned that Google Gears approach is a
good model, but that it would be premature to standardize. I agree
standardizing on the actual Gears API would be strange, however, wouldn't
taking a shared nothing approach to sandboxing (using messaging) like gears
(but with our own API) be a safer and easier to analyze approach to
sandboxing and more reasonable in terms of time constraints for inclusion in
ES4 than the scopable eval? Shared nothing techniques are hardly a new PL
concept, albiet I am sure it is still not a trivial addition.
Just thinking about what it could look like:
mySandbox = new Environment(myScriptToSandbox);
onmessage=function(message : string) {...}
mySandbox.sendMessage(start);
And of course, it seems hard to resist the temptation to entertain the hope
that this could be a possible API for adventurous implementors to use for a
concurrency construct (use the same API for ConcurrentEnvironment), which
could advise ES5's work on concurrency.
Kris
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
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
