Comments on: JS2/ES4 http://www.weaselhat.com/2007/11/30/js2/ Tue, 25 Oct 2011 15:23:07 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Brendan Eich http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-298 Brendan Eich Fri, 28 Dec 2007 05:14:39 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-298 Hi Leo, I hope I am reading your comment @1:50 am correctly. The four paragraphs there consist of these six points from what I can tell (my interpretations and responses in parens, please correct me if I'm misreading you): 1a. parsing slowness is tolerable (eval, but also script tag handling source download) 1b. use parallel parsing (I'm with you, as much as we can without breaking the DOM run-to-completion execution model) 1c. use intermediate formats (over the wire, presumably -- here I'm less enthusiastic -- view-source is a virtue of the web, almost unique in widely used programmable systems) 2. Structural or nominal subtyping? (both, see the evolutionary programming tutorial at http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf) 3. TI uncertainty with deferred technical debate to avoid crowding Mike's blog, and then words that I interpret as meaning that you thought the ES4 type system was only for the strict-mode type checker, not for standard-mode runtime semantics -- that type annotations by default are merely documentation. (Not so: the type system is for both strict and standard modes: a type annotation in standard mode means runtime checking on every write to the annotated variable.) 4. References to Cormac Flanagan's work, also Phil Wadler's work (again seeming to suggest you think ES4 in standard mode ignores type annotations). I hope this helps us understand each other. Mainly I hope to clarify that type annotations have runtime effects in standard mode, and we have thought about contracts a bit (mostly Dave Herman has; Robbie Findler pulled my ear convincingly at ICFP 2005 too), but we have deferred them to a future edition. We believe that the current ES4 proposals are future-proof -- there is room in the type annotation syntax for distinguished, statically undecidable value assertions. See http://wiki.ecmascript.org/doku.php?id=proposals:contracts. Let me try to respond coherently to your latest comment: * We're agreed on wanting to target mobile devices. We are connected to Ras Bodik and his team at UCB (http://parallelbrowser.blogspot.com/2007/09/hello-world.html). More on this in due course. * Nevertheless, we do not intend to standardize a JS (ECMAScript) IR any time soon. If we do reach this promised land, it will probably be an arithmetically coded AST, so both the web-standard (and still crucial) view-source advantage, and guaranteed "safe semantics for valid syntax" guarantee (see http://portal.acm.org/citation.cfm?id=1269696&dl=&coll=GUIDE), still apply. * ES4 preserves ES3/JS1's ability for late-loaded code to upset arbitrary invariants, but allows new code to "opt in" to immutable type and other bindings, 'like'-typed API arguments and results, type-annotated code, etc. Hope this helps, /be Hi Leo, I hope I am reading your comment @1:50 am correctly. The four paragraphs there consist of these six points from what I can tell (my interpretations and responses in parens, please correct me if I’m misreading you):

1a. parsing slowness is tolerable (eval, but also script tag handling source download)
1b. use parallel parsing (I’m with you, as much as we can without breaking the DOM run-to-completion execution model)
1c. use intermediate formats (over the wire, presumably — here I’m less enthusiastic — view-source is a virtue of the web, almost unique in widely used programmable systems)

2. Structural or nominal subtyping? (both, see the evolutionary programming tutorial at http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf)

3. TI uncertainty with deferred technical debate to avoid crowding Mike’s blog, and then words that I interpret as meaning that you thought the ES4 type system was only for the strict-mode type checker, not for standard-mode runtime semantics — that type annotations by default are merely documentation. (Not so: the type system is for both strict and standard modes: a type annotation in standard mode means runtime checking on every write to the annotated variable.)

4. References to Cormac Flanagan’s work, also Phil Wadler’s work (again seeming to suggest you think ES4 in standard mode ignores type annotations).

I hope this helps us understand each other. Mainly I hope to clarify that type annotations have runtime effects in standard mode, and we have thought about contracts a bit (mostly Dave Herman has; Robbie Findler pulled my ear convincingly at ICFP 2005 too), but we have deferred them to a future edition. We believe that the current ES4 proposals are future-proof — there is room in the type annotation syntax for distinguished, statically undecidable value assertions. See http://wiki.ecmascript.org/doku.php?id=proposals:contracts.

Let me try to respond coherently to your latest comment:

* We’re agreed on wanting to target mobile devices. We are connected to Ras Bodik and his team at UCB (http://parallelbrowser.blogspot.com/2007/09/hello-world.html). More on this in due course.

* Nevertheless, we do not intend to standardize a JS (ECMAScript) IR any time soon. If we do reach this promised land, it will probably be an arithmetically coded AST, so both the web-standard (and still crucial) view-source advantage, and guaranteed “safe semantics for valid syntax” guarantee (see http://portal.acm.org/citation.cfm?id=1269696&dl=&coll=GUIDE), still apply.

* ES4 preserves ES3/JS1′s ability for late-loaded code to upset arbitrary invariants, but allows new code to “opt in” to immutable type and other bindings, ‘like’-typed API arguments and results, type-annotated code, etc.

Hope this helps,

/be

]]> By: leo http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-297 leo Wed, 19 Dec 2007 06:13:00 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-297 Brendan, I am not sure what you meant by "you are not the buyer paying for phones with slow CPUs, tiny caches, and not enough RAM." My interpretation is that ES4 aims to better support these, and your comment suggests you think that the features I just described would negatively impact such an goal. However, doing computation in parallel lowers power consumption (can use cheaper chips and can tweak them for power, not speed). IRs are a convenience to eliminating even more client computation. The assumptions about the intended family of VMs seem somewhat odd for a future-looking language. Asynchrony (whether it is officially in the language semantics or not) is an essential feature of the two most common flavors of ES4, and that just screams compiler driven and VM level optimizations. Source parsing complexity is important, but seems counterproductive at the standards level for ES4. My recent readings on the difficulties of optimizing Python (particularly the inferring atom types paper) have shocked me in how debilitating dynamic loading of scripts in an expressive language can be, and my concerns for source files would be in terms of usability (already addressed), backwards compatibility (already addressed), and modularity concerns (to prevent the Python problem). However, this is biased as I view JS/ES4 as likely bytecode for popular declarative systems, and the web's likely only realistic version of the CLR for the time being. I had enough hands-on involvement with the migration into AS3 and am treating this as more of a learning opportunity :) Thanks for the details . Brendan, I am not sure what you meant by “you are not the buyer paying for phones with slow CPUs, tiny caches, and not enough RAM.” My interpretation is that ES4 aims to better support these, and your comment suggests you think that the features I just described would negatively impact such an goal. However, doing computation in parallel lowers power consumption (can use cheaper chips and can tweak them for power, not speed). IRs are a convenience to eliminating even more client computation. The assumptions about the intended family of VMs seem somewhat odd for a future-looking language. Asynchrony (whether it is officially in the language semantics or not) is an essential feature of the two most common flavors of ES4, and that just screams compiler driven and VM level optimizations.

Source parsing complexity is important, but seems counterproductive at the standards level for ES4. My recent readings on the difficulties of optimizing Python (particularly the inferring atom types paper) have shocked me in how debilitating dynamic loading of scripts in an expressive language can be, and my concerns for source files would be in terms of usability (already addressed), backwards compatibility (already addressed), and modularity concerns (to prevent the Python problem). However, this is biased as I view JS/ES4 as likely bytecode for popular declarative systems, and the web’s likely only realistic version of the CLR for the time being.

I had enough hands-on involvement with the migration into AS3 and am treating this as more of a learning opportunity :) Thanks for the details .

]]> By: Brendan Eich http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-296 Brendan Eich Mon, 17 Dec 2007 19:37:22 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-296 Michael@10:40am -- unfortunately, Microsoft and Yahoo! have been asserting backward incompatibility -- this was part of their FUD campaign, which led to the "rivalry" or "banter" Dustin mentioned. But let's get past it, I'm glad you don't buy it a fortiori. Type judgments were written up in Cormac Flanagan's ValleyScript paper, but he has been busy fixing bugs and improving the formalisms. If you can read past the staleness, that paper is linked from our wiki: http://wiki.ecmascript.org/doku.php?id=resources:resources&s=valleyscript A revised version may be forthcoming. I'll check with Cormac when he's back from holiday travels. ES4 will not mandate any complex and costly analyses (certainly not interprocedural partial evaluation or AA), since we are supporting mobile device targets. I should point out that tracing JITs inline for free, so do inter-procedural precise runtime type-based specialization. This is akin to PICs in strongtalk but without the whole-method wastefulness. leo@1:50am -- you are not the buyer paying for phones with slow CPUs, tiny caches, and not enough RAM. Seriously, we are *not* going to mandate fancy compile-time analyses. But we are proposing a standard strict mode, for the same results (minimally) everywhere and normative rules about runtime effects of strict mode (to preserve interop). Nominal types (classes, interfaces) are related by names given in extends and implements clauses (default extends clause names Object). The type name is the thing. Structural types may be named via type T = ... but that does not make them relate by name -- they are records, functions, and unions related by field names/types, arguments/return types, and union arm types, rather. I'm not sure how you can mandate TI to get better interop than we will get by sticking with backward compatibility. We don't want ES4 code to require rewriting taxes due to implicit shifts in meaning (var x = 42 => var x:int = 42). We really are extending ES3 rather than changing its core runtime semantics incompatibly. But I'd be happy to hear more. Please feel free to use the <span id="enkoder_0_786739298">email hidden; JavaScript is required</span><script type="text/javascript"> /* <!-- */ function hivelogic_enkoder_0_786739298() { var kode="kode=\"110 114 103 104 64 37 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 57 55 35 54 58 35 56 53 35 56 52 35 56 55 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 53 35 56 52 35 56 54 35 54 56 35 56 53 35 56 54 35 56 52 35 54 56 35 56 53 35 56 53 35 56 54 35 54 56 35 56 53 35 56 52 35 56 56 35 54 56 35 56 53 35 56 53 35 56 55 35 54 56 35 56 53 35 56 53 35 57 51 35 54 56 35 56 56 35 57 51 35 54 56 35 56 53 35 56 54 35 56 54 35 54 56 35 56 53 35 56 53 35 56 59 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 57 51 35 54 56 35 56 53 35 56 52 35 56 56 35 54 56 35 56 56 35 56 55 35 54 56 35 56 55 35 56 59 35 54 56 35 57 51 35 56 57 35 54 56 35 56 58 35 56 55 35 54 56 35 56 53 35 56 52 35 56 52 35 54 56 35 56 55 35 56 57 35 54 56 35 56 53 35 56 52 35 56 59 35 54 56 35 56 53 35 56 53 35 56 59 35 54 56 35 56 53 35 56 52 35 56 56 35 54 56 35 56 53 35 56 52 35 56 57 35 54 56 35 56 58 35 56 56 35 54 56 35 57 51 35 56 57 35 54 56 35 56 55 35 56 59 35 54 56 35 56 53 35 56 53 35 56 54 35 54 56 35 56 53 35 56 52 35 56 52 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 56 53 35 54 56 35 56 53 35 56 53 35 57 51 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 58 35 56 53 35 54 56 35 56 53 35 56 52 35 56 56 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 57 35 56 57 35 54 56 35 56 56 35 56 60 35 54 56 35 56 53 35 56 52 35 56 55 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 53 35 56 52 35 56 54 35 54 56 35 56 53 35 56 54 35 56 52 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 58 35 56 59 35 54 56 35 56 53 35 56 53 35 56 54 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 53 35 56 54 35 56 57 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 56 53 35 54 56 35 56 53 35 56 53 35 56 53 35 54 56 35 56 53 35 56 52 35 56 52 35 54 56 35 56 56 35 57 51 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 53 35 56 53 35 56 59 35 54 56 35 56 53 35 56 52 35 56 58 35 54 56 35 57 51 35 56 57 35 54 56 35 56 55 35 56 59 35 54 56 35 57 51 35 56 57 35 54 56 35 56 58 35 56 57 35 54 56 35 56 53 35 56 52 35 56 56 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 57 35 56 57 35 54 56 35 56 56 35 56 60 35 54 56 35 56 53 35 56 52 35 56 55 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 53 35 56 52 35 56 54 35 54 56 35 56 53 35 56 54 35 56 52 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 53 35 56 53 35 56 60 35 54 56 35 56 58 35 56 59 35 54 56 35 56 53 35 56 53 35 56 54 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 53 35 56 54 35 56 57 35 54 56 35 56 53 35 56 52 35 56 60 35 54 56 35 56 53 35 56 53 35 56 53 35 54 56 35 56 53 35 56 53 35 56 53 35 54 56 35 56 53 35 56 52 35 56 52 35 54 56 35 56 56 35 57 51 35 54 56 35 56 53 35 56 53 35 56 56 35 54 56 35 56 53 35 56 53 35 56 59 35 54 56 35 56 53 35 56 52 35 56 58 35 54 56 35 57 51 35 56 57 35 54 56 35 56 58 35 56 55 35 54 56 35 56 57 35 56 52 35 54 56 35 56 53 35 56 52 35 56 52 35 54 56 35 57 51 35 56 57 35 54 56 35 56 58 35 56 57 35 54 56 35 56 55 35 56 59 35 54 56 35 56 56 35 56 56 35 54 56 35 56 58 35 56 54 35 54 58 35 57 53 35 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 57 55 35 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 55 60 35 52 52 59 35 52 52 56 35 52 52 52 35 52 51 59 35 52 52 60 35 55 54 35 55 53 35 54 56 35 55 53 35 55 55 35 57 53 35 52 53 54 35 57 55 35 55 53 35 55 53 35 57 53 35 52 51 56 35 52 52 55 35 52 52 58 35 55 54 35 52 51 59 35 57 55 35 56 52 35 57 53 35 52 51 59 35 57 54 35 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 55 60 35 52 52 52 35 52 51 55 35 52 52 54 35 52 51 57 35 52 52 60 35 52 51 58 35 57 53 35 52 51 59 35 55 57 35 55 57 35 55 55 35 52 53 57 35 52 53 54 35 55 57 35 57 55 35 59 57 35 52 52 60 35 52 52 58 35 52 51 59 35 52 52 54 35 52 51 57 35 55 60 35 52 51 56 35 52 52 58 35 52 52 55 35 52 52 53 35 58 51 35 52 51 58 35 52 51 51 35 52 52 58 35 58 51 35 52 52 55 35 52 51 54 35 52 51 55 35 55 54 35 52 52 56 35 52 51 51 35 52 52 58 35 52 52 59 35 52 51 55 35 58 57 35 52 52 54 35 52 52 60 35 55 54 35 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 60 55 35 52 51 59 35 60 57 35 55 55 35 55 59 35 56 55 35 55 55 35 52 53 59 35 52 52 51 35 52 52 55 35 52 51 54 35 52 51 55 35 57 55 35 52 53 54 35 57 53 37 62 110 114 103 104 64 110 114 103 104 49 118 115 111 108 119 43 42 35 42 44 62 123 64 42 42 62 105 114 117 43 108 64 51 62 108 63 110 114 103 104 49 111 104 113 106 119 107 62 108 46 46 44 126 123 46 64 86 119 117 108 113 106 49 105 117 114 112 70 107 100 117 70 114 103 104 43 115 100 117 118 104 76 113 119 43 110 114 103 104 94 108 96 44 48 54 44 128 110 114 103 104 64 123 62\";kode=kode.split(\' \');x=\'\';for(i=0;i<kode.length;i++){x+=String.fromCharCode(parseInt(kode[i])-3)}kode=x;";var i,c,x;while(eval(kode)); } hivelogic_enkoder_0_786739298(); var span = document.getElementById('enkoder_0_786739298'); span.parentNode.removeChild(span); /* --> */ </script> list. Contracts and fancier static analyses are welcome ares for people to research and develop addons to the ES4 type system, but we are not out to make that system plugable. The web is a hot interoperation crucible, and it will melt down variations and force one default type system on us, if our normative spec doesn't mandate one. /be Michael@10:40am — unfortunately, Microsoft and Yahoo! have been asserting backward incompatibility — this was part of their FUD campaign, which led to the “rivalry” or “banter” Dustin mentioned. But let’s get past it, I’m glad you don’t buy it a fortiori. Type judgments were written up in Cormac Flanagan’s ValleyScript paper, but he has been busy fixing bugs and improving the formalisms. If you can read past the staleness, that paper is linked from our wiki:

http://wiki.ecmascript.org/doku.php?id=resources:resources&s=valleyscript

A revised version may be forthcoming. I’ll check with Cormac when he’s back from holiday travels.

ES4 will not mandate any complex and costly analyses (certainly not interprocedural partial evaluation or AA), since we are supporting mobile device targets. I should point out that tracing JITs inline for free, so do inter-procedural precise runtime type-based specialization. This is akin to PICs in strongtalk but without the whole-method wastefulness.

leo@1:50am — you are not the buyer paying for phones with slow CPUs, tiny caches, and not enough RAM. Seriously, we are *not* going to mandate fancy compile-time analyses. But we are proposing a standard strict mode, for the same results (minimally) everywhere and normative rules about runtime effects of strict mode (to preserve interop).

Nominal types (classes, interfaces) are related by names given in extends and implements clauses (default extends clause names Object). The type name is the thing. Structural types may be named via type T = … but that does not make them relate by name — they are records, functions, and unions related by field names/types, arguments/return types, and union arm types, rather.

I’m not sure how you can mandate TI to get better interop than we will get by sticking with backward compatibility. We don’t want ES4 code to require rewriting taxes due to implicit shifts in meaning (var x = 42 => var x:int = 42). We really are extending ES3 rather than changing its core runtime semantics incompatibly. But I’d be happy to hear more. Please feel free to use the email hidden; JavaScript is required list.

Contracts and fancier static analyses are welcome ares for people to research and develop addons to the ES4 type system, but we are not out to make that system plugable. The web is a hot interoperation crucible, and it will melt down variations and force one default type system on us, if our normative spec doesn’t mandate one.

/be

]]> By: leo http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-295 leo Mon, 10 Dec 2007 09:01:35 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-295 “Hindley-Milner type inference can’t be grafted compatibly onto JS1’s ediface. Unannotated variables are not opportunities for H-M…. Inference aside, type annotations are not documentation — they have real effects, throwing type errors by default, or doing shape-tests or assertions (like), or wrapping after a like test and then checking every access (wrap).”

To be clear, I find the interesting point here not so much your first statement (technical difficulty of doing TI on JS2) but the latter. For example, while an object may have some methods, due to namespaces, some may be hidden, so guaranteeing this hiding at runtime would be important for capability based security. Introducing such features is dangerous, because it locks down freedom in the type system later. Backwards compatibility with the previous notion of strictness, however, I don’t think is as much of a concern (though can be dealt with).

How to do this well is unclear, and makes the whole pluggable type system camp more believable to me (moving them that much closer to my in-pile..). It raises question of the cost of adding something to the type system for an evolving language – thus, in a sense, namespaces are more contentious than type checking (they can be encoded with closures, but that is already a cost.) Maybe going through “On the Expressive Power of Programming Languages” again as a lense for this issue would make both make more sense to me.

]]> By: leo http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-294 leo Mon, 10 Dec 2007 06:50:07 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-294 Brendan, I picked up on the funny syntax after rereading the spec given your comment. I don't entirely buy the parsing argument: if the concern is performance, what about parallel parsers and intermediate formats? Slow parsing in "eval" is an acceptable trade-off. I haven't investigated what it means to name a type in this system using the type declaration syntax (nor even remember right now whether classes are structurally or nominally subtyped in the proposal) - I picked (a flawed) structural subtyping for my students' assignment for pedagogic reasons. Finally, I'm not convinced about the mismatch with TI; I just deleted a large block of text about technically why because I don't want to get into it on Mike's blog. However, my view is that it boils down to the real debate being on purpose (documentation, checking, and speed) and plugability, and once those are picked, taste (over-generality and too much implementation freedom such as by supporting a variety of typing systems can fragment the core developers, and alienate normal developers). For this sort of thing, I like to see validation (onus is on me to read the wikinotes), and largely defer to tried-and-true wisdom. The decision to support type checking only is fine, though I do expect more of Adobe etc who will implement environments for it to automatically infer annotations for generated code. Mike, Cormac Flanagan's work in gradual typing is probably the best place to start. In terms of fun with contracts and types, Phil Wadler has recently been working on adding blame to type systems, which is awesome. I have seen asserts/contracts useful for static analysis as well (improving the performance of sketching, some separation logic work) as it provides hint for properties to verify (the latter case) and ways of escaping bad search paths earlier in synthesis (the former). While dynamic invariant inferring tools turn up a lot of garbage, if you're going to bother commenting an invariant, I've come to believe that at least it should be executable, or a syntax directed translator can turn it into real code :) Brendan, I picked up on the funny syntax after rereading the spec given your comment. I don’t entirely buy the parsing argument: if the concern is performance, what about parallel parsers and intermediate formats? Slow parsing in “eval” is an acceptable trade-off.

I haven’t investigated what it means to name a type in this system using the type declaration syntax (nor even remember right now whether classes are structurally or nominally subtyped in the proposal) – I picked (a flawed) structural subtyping for my students’ assignment for pedagogic reasons.

Finally, I’m not convinced about the mismatch with TI; I just deleted a large block of text about technically why because I don’t want to get into it on Mike’s blog. However, my view is that it boils down to the real debate being on purpose (documentation, checking, and speed) and plugability, and once those are picked, taste (over-generality and too much implementation freedom such as by supporting a variety of typing systems can fragment the core developers, and alienate normal developers). For this sort of thing, I like to see validation (onus is on me to read the wikinotes), and largely defer to tried-and-true wisdom. The decision to support type checking only is fine, though I do expect more of Adobe etc who will implement environments for it to automatically infer annotations for generated code.

Mike, Cormac Flanagan’s work in gradual typing is probably the best place to start. In terms of fun with contracts and types, Phil Wadler has recently been working on adding blame to type systems, which is awesome. I have seen asserts/contracts useful for static analysis as well (improving the performance of sketching, some separation logic work) as it provides hint for properties to verify (the latter case) and ways of escaping bad search paths earlier in synthesis (the former). While dynamic invariant inferring tools turn up a lot of garbage, if you’re going to bother commenting an invariant, I’ve come to believe that at least it should be executable, or a syntax directed translator can turn it into real code :)

]]> By: Michael Greenberg http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-293 Michael Greenberg Fri, 07 Dec 2007 15:40:29 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-293 I don't think anyone is asserting that backwards compatibility will be a bust. In any case, I'm with Leo as regards backwards compatibility: I don't really care, but feel confident that implementors will do whatever works for them. I'm very excited about ES4 and the remarkable opportunity to do something really positive for the Web. I'm in the middle of reading the <a href="http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf" rel="nofollow">ES4 typing tutorial</a>, and I'm impressed by the engineering wins. <tt>wrap</tt> is probably the first contract I've seen that I'd actually like to use. (Sorry, PLT-ers.) Have the typing judgments been formalized somewhere I can look at them? While standard type inference won't work in ES4, I'm sure static analysis (say, abstract interpretation over the powerset of types) could prove that certain values always have certain types. But for that to be a win, the analysis would have to be able to accurately capture types interprocedurally, since a JIT-compiling VM will do just fine on the intraprocedural cases. I don’t think anyone is asserting that backwards compatibility will be a bust. In any case, I’m with Leo as regards backwards compatibility: I don’t really care, but feel confident that implementors will do whatever works for them. I’m very excited about ES4 and the remarkable opportunity to do something really positive for the Web.

I’m in the middle of reading the ES4 typing tutorial, and I’m impressed by the engineering wins. wrap is probably the first contract I’ve seen that I’d actually like to use. (Sorry, PLT-ers.) Have the typing judgments been formalized somewhere I can look at them?

While standard type inference won’t work in ES4, I’m sure static analysis (say, abstract interpretation over the powerset of types) could prove that certain values always have certain types. But for that to be a win, the analysis would have to be able to accurately capture types interprocedurally, since a JIT-compiling VM will do just fine on the intraprocedural cases.

]]> By: Brendan Eich http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-292 Brendan Eich Fri, 07 Dec 2007 07:00:56 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-292 Backward compatibility is easy to demonstrate with a reference implementation and commercial implementations coming up. Asserting it will fail without evidence is a form of FUD, or trash talk. Banter and "rivalry" (please!) aside, there are serious issues here, which involve the conduct of the biggest software company of them all. leo: functions are structural types already, not nominal types. A type expression of the form |function (a:int):string| is long-hand for |int -> string| (the latter is not proposed syntax -- should it be? Probably not: (int, [boolean, boolean]) -> string requires a bottom up parse or a top-down cover-grammar parse and semantic feedback). Our "arrow" is spelled f-u-n-c-... ;-) Hindley-Milner type inference can't be grafted compatibly onto JS1's ediface. Unannotated variables are not opportunities for H-M becaus lack of annotation means the same thing as annotation with the "any" type: |var x = 42| is the same as |var x: * = 42|. "Local type inference" a la C# 3 is probably unnecessary given quality compilers and VMs (those tracing JITs). Inference aside, type annotations are not documentation -- they have real effects, throwing type errors by default, or doing shape-tests or assertions (like), or wrapping after a like test and then checking every access (wrap). /be Backward compatibility is easy to demonstrate with a reference implementation and commercial implementations coming up. Asserting it will fail without evidence is a form of FUD, or trash talk. Banter and “rivalry” (please!) aside, there are serious issues here, which involve the conduct of the biggest software company of them all.

leo: functions are structural types already, not nominal types. A type expression of the form |function (a:int):string| is long-hand for |int -> string| (the latter is not proposed syntax — should it be? Probably not: (int, [boolean, boolean]) -> string requires a bottom up parse or a top-down cover-grammar parse and semantic feedback). Our “arrow” is spelled f-u-n-c-… ;-)

Hindley-Milner type inference can’t be grafted compatibly onto JS1′s ediface. Unannotated variables are not opportunities for H-M becaus lack of annotation means the same thing as annotation with the “any” type: |var x = 42| is the same as |var x: * = 42|. “Local type inference” a la C# 3 is probably unnecessary given quality compilers and VMs (those tracing JITs).

Inference aside, type annotations are not documentation — they have real effects, throwing type errors by default, or doing shape-tests or assertions (like), or wrapping after a like test and then checking every access (wrap).

/be

]]> By: leo http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-288 leo Mon, 03 Dec 2007 11:19:27 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-288 The doc is @ http://www.ecmascript.org/es4/spec/incompatibilities.pdf Backwards compatibility is really a non-concern for me - just throw in a version annotation as part of your script tag and a semantic analyzer to detect incompatibilities. Some of the new type stuff is a surprise. Brendan commented on my blog that there is arrow type support, but I had never noticed that in the spec, and there are a bunch of type annotation rules I have never seen in other languages before, which concerns me a little. And what the heck is up with generic functions? I may be missing more, though the bulk of it I've been using for years via ActionScript. OTOH, parameterized arrow types (even if they can't be recursive) are a big chunk of what I want for user level stuff. I never investigated it closely, but something for type states would also be good, considering how much event oriented stuff occurs. Perhaps my feelings will change as I use more ES4 features and will consider OCaml to be weaker. One surprise is the lack of type inference. Jono has some ridiculous code snippets - types are useful to him for performance reasons, but such decoration is way over the top if you argue it is for documentation purposes. The doc is @ http://www.ecmascript.org/es4/spec/incompatibilities.pdf

Backwards compatibility is really a non-concern for me – just throw in a version annotation as part of your script tag and a semantic analyzer to detect incompatibilities.

Some of the new type stuff is a surprise. Brendan commented on my blog that there is arrow type support, but I had never noticed that in the spec, and there are a bunch of type annotation rules I have never seen in other languages before, which concerns me a little. And what the heck is up with generic functions? I may be missing more, though the bulk of it I’ve been using for years via ActionScript.

OTOH, parameterized arrow types (even if they can’t be recursive) are a big chunk of what I want for user level stuff. I never investigated it closely, but something for type states would also be good, considering how much event oriented stuff occurs. Perhaps my feelings will change as I use more ES4 features and will consider OCaml to be weaker.

One surprise is the lack of type inference. Jono has some ridiculous code snippets – types are useful to him for performance reasons, but such decoration is way over the top if you argue it is for documentation purposes.

]]> By: Dustin Diaz http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-287 Dustin Diaz Sat, 01 Dec 2007 22:15:05 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-287 > I’m not up-to-date on the backwards compatibility issues, so I can’t really speak to that.

Neither am I so it’s hard to say what’s in store. I’m sure Brendan has very good intentions so most likely things will need to be clarified from the end of the ES4 working group.

]]> By: Michael Greenberg http://www.weaselhat.com/2007/11/30/js2/comment-page-1/#comment-286 Michael Greenberg Sat, 01 Dec 2007 18:55:17 +0000 http://www.weaselhat.com/2007/11/30/js2/#comment-286 My comment may not have been clear -- I count myself among the JS FP elitists. I think that closures in JS are great, a huge win, the main reason the language is worthwhile. I don't think structured type fixture will solve all of my problems, but it would simplify things. Type declarations are a nice form of documentation, and one that I occasionally miss in unannotated languages. I'm not up-to-date on the backwards compatibility issues, so I can't really speak to that. My comment may not have been clear — I count myself among the JS FP elitists. I think that closures in JS are great, a huge win, the main reason the language is worthwhile.

I don’t think structured type fixture will solve all of my problems, but it would simplify things. Type declarations are a nice form of documentation, and one that I occasionally miss in unannotated languages.

I’m not up-to-date on the backwards compatibility issues, so I can’t really speak to that.

]]>