├── as4wp ├── AS4wp121031.pdf ├── same.tex ├── document.tex ├── frontmatter.tex ├── outlook.tex ├── intro.tex ├── dropped.tex ├── new.tex └── changes.tex ├── as4lang └── as4langspec.pdf ├── third-party ├── mathpartir │ ├── mathpartir.sty │ └── LICENSE └── README.md ├── NOTICE ├── README.md └── LICENSE /as4wp/AS4wp121031.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adobe-research/ActionScript4/HEAD/as4wp/AS4wp121031.pdf -------------------------------------------------------------------------------- /as4lang/as4langspec.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adobe-research/ActionScript4/HEAD/as4lang/as4langspec.pdf -------------------------------------------------------------------------------- /third-party/mathpartir/mathpartir.sty: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/adobe-research/ActionScript4/HEAD/third-party/mathpartir/mathpartir.sty -------------------------------------------------------------------------------- /third-party/README.md: -------------------------------------------------------------------------------- 1 | This folder is where all third party code should go. 2 | 3 | Each third party library should be in a separate folder and it should 4 | contain a license file for said library. 5 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright 2012 Adobe Systems Incorporated 2 | 3 | This software is licensed under the Apache License, Version 2.0 (see 4 | LICENSE file). 5 | 6 | This software uses the following third party libraries that may have 7 | licenses differing from that of the software itself. You can find the 8 | libraries and their respective licenses below. 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ActionScript4 2 | ============= 3 | 4 | ActionScript 4 Language Reference, Virtual Machine Specification and 5 | White Paper 6 | 7 | Adobe and ActionScript are either registered trademarks or trademarks 8 | of Adobe Systems Incorporated in the United States and/or other 9 | countries. All other trademarks are the property of their respective 10 | owners. No right or license is granted to any Adobe trademark. 11 | 12 | Adobe is publishing the ActionScript 4 specifications in the hope that 13 | they may be useful to the programming language and managed runtime 14 | communities. The specifications are as they existed when the project 15 | with which they were associated was discontinued and therefore may be 16 | considered incomplete. Source code for the compiler and runtime is 17 | not available. Adobe has no plans to resume development of 18 | ActionScript 4. 19 | 20 | The Latex source code (the .tex files) for the Language Reference and 21 | White Paper is licensed under the Apache License Version 2.0, while 22 | the corresponding specifications are licensed under the Creative 23 | Commons Attribution Non-Commercial 3.0 License. The Virtual Machine 24 | Specification draft, which is a text file, is licensed under the 25 | Apache License Version 2.0. 26 | -------------------------------------------------------------------------------- /as4wp/same.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{Implementation Notes} 16 | \label{impl} 17 | \subsection{Automatic Boxing and Unboxing} 18 | 19 | In AS4 we distinguish between value types, reference types, and \code{*}. 20 | Inhabitants of value types are directly 21 | laid out in memory, registers, and on the stack, and are compared by 22 | value; and furthermore, their types are tracked by the compiler. 23 | Inhabitants of reference types are represented by pointers into memory, and are 24 | compared by reference; and furthermore, their types are manifest in 25 | the payload. 26 | 27 | The \code{*} type is a (tagged) union of value types and reference 28 | types. Inhabitants of \code{*} are represented by a pointer into 29 | memory (``boxing''). (Crucially, this means that unlike in AS3, 30 | inhabitants of value types and inhabitants of \code{*} always have 31 | distinct representations, and are never confused. Type inference at 32 | the source-code level ``unboxes'' as many inhabitants of \code{*} as 33 | possible, but the run-time does not need to worry about such type inference.) 34 | Boxing a value makes the type manifest, and boxing a reference is a 35 | no-op. Furthermore, inhabitants of \code{*} behave exactly like their unboxed versions modulo boxing. 36 | 37 | Subtyping and conversion are distinct notions in AS4. Subtyping 38 | does not change representation and semantics; 39 | e.g., class $B$ is a subtype of class $A$ if $B$ is a subclass 40 | of $A$, so a reference of type $B$ can be freely passed to a 41 | context of type $A$. 42 | 43 | Implicit conversion, on the other hand, 44 | changes representation or semantics; 45 | e.g., \code{int} is implicitly convertible to \code{double} or 46 | \code{*}. Crucially, the 47 | compiler makes all implicit conversions explicit (via 48 | coercions). This means that the 49 | runtime works on explicitly typed code (possibly with 50 | coercions): it never needs to know about implicit conversions. 51 | In particular, the compiler cleanly separates fast paths and slow paths. 52 | So the runtime can generate fast machine code for statically typed parts 53 | of the source code without any type inference (and is \emph{not} obligated to 54 | generate optimized machine code for dynamically typed parts of the 55 | source code). 56 | 57 | \subsection{Verification} 58 | 59 | As a result of the above separation of duties of the compiler and the 60 | run-time, a bytecode verifier for AS4 (unlike AS3) need not do any 61 | type inference and/or bytecode rewriting. All it does is typecheck the 62 | bytecode, following the typechecking performed by the source-level 63 | compiler. 64 | 65 | This model enables a source-level compiler to freely and aggressively perform 66 | type-based optimizations: for example, it can rely on the types of 67 | library classes that a program is compiled against, even those such 68 | classes may not be included in the generated bytecode. At run time, 69 | those type assumptions are validated by the verifier, which means that 70 | different versions of such library classes can be dynamically loaded 71 | and the generated bytecode continues to run as long as the types it 72 | relies on at compile-time remain invariant at run-time. 73 | -------------------------------------------------------------------------------- /as4wp/document.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \input{frontmatter.tex} 16 | 17 | \title{White Paper: Introducing the ActionScript\textsuperscript{\textregistered} 4 18 | Language} \author{Bernd Mathiske, Avik Chaudhuri, Krzysztof Palacz, and Basil Hosmer\\ 19 | \\ 20 | {\it Adobe Systems Incorporated} \\ 21 | {\tt AS4@adobe.com}} 22 | %\date{} % Activate to display a given date or no date 23 | 24 | \begin{document} 25 | 26 | \maketitle 27 | 28 | \pagebreak 29 | 30 | \copyright{} 2014 Adobe Systems Incorporated. All rights reserved. %[update year of publication] 31 | 32 | {\bf Adobe ActionScript 4 Language White Paper Version 1.0} 33 | 34 | This document is protected under copyright law, furnished for informational use 35 | only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. 36 | Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies 37 | that may appear in the informational content contained in this guide. 38 | 39 | This guide contains links to third-party websites that are not under the control of Adobe Systems 40 | Incorporated, and Adobe Systems Incorporated is not responsible for the content on any linked site. 41 | If you access a third-party website mentioned in this guide, then you do so at your own risk. Adobe 42 | Systems Incorporated provides these links only as a convenience, and the inclusion of the link does 43 | not imply that Adobe Systems Incorporated endorses or accepts any responsibility for the content on 44 | those third-party sites. No right, license, or interest is granted in any third party technology 45 | referenced in this guide. 46 | 47 | This user guide is licensed for use under the terms of the Creative Commons Attribution 48 | Non-Commercial 3.0 License. This License allows users to copy, distribute, and transmit the user 49 | guide for noncommercial purposes only so long as (1) proper attribution to Adobe is given as the 50 | owner of the user guide; and (2) any reuse or distribution of the user guide contains a notice that 51 | use of the user guide is governed by these terms. The best way to provide notice is to include the 52 | following link. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/. 53 | 54 | Adobe, Adobe AIR, ActionScript, and Flash are either registered 55 | trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. All other trademarks are the 56 | property of their respective owners. No right or license is granted to any Adobe trademark. 57 | %Updated Information/Additional Third Party Code Information 58 | %available at http://www.adobe.com/go/thirdparty. 59 | 60 | Adobe Systems Incorporated, 345 Park Avenue, San Jose, California 95110, USA. 61 | 62 | \emph{Notice to U.S. Government End Users:} The Software and Documentation are ``Commercial Items,'' as 63 | that term is defined at 48 C.F.R. \S2.101, consisting of ``Commercial Computer Software'' and 64 | ``Commercial Computer Software Documentation,'' as such terms are used in 48 C.F.R. \S12.212 65 | or 48 C.F.R. \S227.7202, as applicable. Consistent with 48 C.F.R. \S12.212 or 48 C.F.R. 66 | \S\S227.7202-1 through 227.7202-4, as applicable, the Commercial Computer Software and 67 | Commercial Computer Software Documentation are being licensed to U.S. Government end users (a) only 68 | as Commercial Items and (b) with only those rights as are granted to all other end users pursuant 69 | to the terms and conditions herein. Unpublished-rights reserved under the copyright laws of the 70 | United States. Adobe agrees to comply with all applicable equal opportunity 71 | laws including, if appropriate, the provisions of Executive Order 11246, as amended, Section 402 of the Vietnam Era 72 | Veterans Readjustment Assistance Act of 1974 (38 USC 4212), and Section 503 of the Rehabilitation 73 | Act of 1973, as amended, and the regulations at 41 CFR Parts 60-1 through 60-60, 60-250, and 60-741. 74 | The affirmative action clause and regulations contained in the preceding 75 | sentence shall be incorporated by reference. 76 | 77 | \pagebreak 78 | 79 | \tableofcontents 80 | 81 | \pagebreak 82 | 83 | \input{intro.tex} 84 | \input{dropped.tex} 85 | \input{changes.tex} 86 | \input{new.tex} 87 | \input{outlook.tex} 88 | 89 | \appendix 90 | \input{same.tex} 91 | %\input{appendix.tex} 92 | 93 | \end{document} 94 | -------------------------------------------------------------------------------- /as4wp/frontmatter.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \documentclass[10pt,oneside]{article} 16 | \usepackage{inconsolata} 17 | \usepackage[T1]{fontenc} 18 | \usepackage{microtype} 19 | \DisableLigatures{encoding = *, family = * } 20 | \usepackage{upquote} 21 | \usepackage[usenames,dvipsnames]{color} 22 | \usepackage{fullpage} 23 | \usepackage[parfill]{parskip} % Activate to begin paragraphs with an empty line rather than an indent 24 | \usepackage{graphicx} 25 | \usepackage{amssymb} 26 | \usepackage{epstopdf} 27 | \usepackage{amsthm} 28 | \usepackage{../third-party/mathpartir/mathpartir} 29 | \usepackage[usenames,dvipsnames]{color} 30 | \DeclareGraphicsRule{.tif}{png}{.png}{`convert #1 `dirname #1`/`basename #1 .tif`.png} 31 | 32 | \DeclareFixedFont{\slantsf}{T1}{cmss}{m}{sl}{10} 33 | \DeclareFixedFont{\slantsffootnote}{T1}{cmss}{m}{sl}{8} 34 | \DeclareFixedFont{\slantsfsmall}{T1}{cmss}{m}{sl}{9} 35 | 36 | \definecolor{WikiBlue}{rgb}{0.2,0.2,.5} 37 | 38 | \renewcommand{\labelenumiv}{\Roman{enumiv}.} 39 | 40 | 41 | \usepackage[linkbordercolor={1 1 1},colorlinks=true,linkcolor=WikiBlue,urlcolor=WikiBlue]{hyperref} 42 | 43 | \usepackage{listings} 44 | \lstset{language=Java,numbers=left,numberstyle=\tiny,numbersep=5pt,basicstyle=\small\ttfamily,commentstyle=\rmfamily,columns=flexible,frame=none,texcl=true,mathescape=true,lineskip=1pt,escapeinside={/**}{*/},showstringspaces=false,otherkeywords={assert} 45 | } 46 | 47 | \setcounter{secnumdepth}{3} 48 | 49 | \setlength{\marginparwidth}{1.2in} 50 | \reversemarginpar 51 | \let\oldmarginpar\marginpar 52 | \renewcommand\marginpar[1]{\-\oldmarginpar[\raggedleft\footnotesize #1]% 53 | {\raggedright\footnotesize #1}} 54 | 55 | %\makeatletter 56 | %\renewcommand{\l@section}{\@dottedtocline{1}{1.5em}{1.0em}} 57 | %\renewcommand{\l@subsection}{\@dottedtocline{2}{2.5em}{1.7em}} 58 | %\renewcommand{\l@subsubsection}{\@dottedtocline{3}{4.2em}{2.8em}} 59 | %\makeatother 60 | 61 | \newcounter{parnum}[section] 62 | \newcommand{\N}{\addtocounter{parnum}{1}\marginpar{\quad\arabic{chapter}.\arabic{section}(\arabic{parnum})}} 63 | 64 | \newcounter{prod} 65 | \newcounter{notemark} 66 | \newcounter{tmp} 67 | \newcounter{base} 68 | 69 | \newcommand{\tag}[1]{${}_{~\!\!\mathtt{#1}}$} 70 | \newcommand{\note}[1]{{\scriptsize #1}} 71 | \newcommand{\condition}[1]{\note{$\langle$#1$\rangle$}} 72 | \newcommand{\grammarprod}{\addtocounter{prod}{1}\\{\tiny 73 | \arabic{prod}} \>} 74 | \newcommand{\grammarproD}{\addtocounter{prod}{1}{\tiny 75 | \arabic{prod}} $~~~~$ \=} 76 | %\newcommand{\grammardef}{} 77 | %\newcommand{\punctuator}[1]{$\mathtt{#1}$} 78 | %\newcommand{\punctuator}[1]{\verb`#1`} 79 | %\newcommand{\nonterminal}[1]{{\it #1}} 80 | 81 | \newcommand{\nonterminal}[1]{{\slantsf #1}} 82 | \newcommand{\lexicalnonterminal}[1]{{\sf #1}} 83 | \newcommand{\terminal}[1]{{\tt #1}} 84 | %\renewcommand{\not}{$\neg$} 85 | %\renewcommand{\lor}{$|~$} 86 | %\newcommand{\noxmlwhitespace}{\condition{no 87 | % \lexicalnonterminal{XMLWhitespace}}} 88 | \newcommand{\nolineterminator}{\condition{\underline{noLineTerminator}}} 89 | \newcommand{\lookaheadnotbegin}{\note{$\langle$lookahead not }} 90 | \newcommand{\lookaheadnotend}{\note{$\rangle$}} 91 | \newcommand{\butnotbegin}{\note{$\langle$\underline{but not} }} 92 | \newcommand{\butnotend}{\note{$\rangle$}} 93 | \newcommand{\butnoembeddedbegin}{\note{$\langle$but no embedded }} 94 | \newcommand{\butnoembeddedend}{\note{$\rangle$}} 95 | 96 | \newcommand{\tagbegin}[1]{\note{$\langle$\underline{#1} }} 97 | \newcommand{\tagend}{\note{$\rangle$}} 98 | \newcommand{\ortag}{\underline{or}} 99 | 100 | \newtheoremstyle{note}% name of the style to be used 101 | {5pt}% measure of space to leave above the theorem. E.g.: 3pt 102 | {5pt}% measure of space to leave below the theorem. E.g.: 3pt 103 | {}% name of font to use in the body of the theorem 104 | {}% measure of space to indent 105 | {\bf}% name of head font 106 | {.}% punctuation between head and body 107 | { }% space after theorem head; " " = normal interword space 108 | {}% Manually specify head 109 | 110 | \theoremstyle{note} 111 | \newtheorem{definition}{Definition}[section] 112 | 113 | %\renewcommand{\labelitemi}{} 114 | 115 | \newenvironment{notes} 116 | {\footnotesize\color{Red}\underline{\arabic{notemark}}} 117 | {\normalsize\vspace*{5pt}} 118 | 119 | \newcommand{\marknote}{\setcounter{base}{\value{prod}}\addtocounter{notemark}{1}$\:{}^{\color{Red}\underline{\arabic{notemark}}}$} 120 | 121 | \newcommand{\prodnum}[1] 122 | {\setcounter{tmp}{\value{base}}\addtocounter{base}{#1}{\tiny\arabic{base}:}\setcounter{base}{\value{tmp}}} 123 | 124 | %MACROS FOR COMMENTS 125 | \newcommand{\avik}[1]{\textcolor{RoyalBlue}{{\bf Avik:} #1}} 126 | \newcommand{\jeff}[1]{\textcolor{RoyalBlue}{{\bf Jeff:} #1}} 127 | \newcommand{\lars}[1]{\textcolor{RoyalBlue}{{\bf Lars:} #1}} 128 | \newcommand{\basil}[1]{\textcolor{RoyalBlue}{{\bf Basil:} #1}} 129 | 130 | %Useful markup 131 | \newcommand{\informative}[1]{{\bf Informative note:} #1} 132 | \newcommand{\example}[1]{{\bf Example:} #1} 133 | \newcommand{\rationale}[1]{{\bf Rationale:} #1} 134 | \newcommand{\todo}[1]{\textcolor{Red}{{\bf TODO:} #1}} 135 | \newcommand{\implnote}[1]{{\bf Implementation note:} #1} 136 | \newcommand{\method}[1]{{\tt #1}} 137 | \newcommand{\operator}[1]{{\tt #1}} 138 | \newcommand{\instruction}[1]{{\tt #1}} 139 | \newcommand{\expression}[1]{{\tt #1}} 140 | \newcommand{\subr}[1]{{\bf #1}} 141 | \newcommand{\argument}[1]{{\em #1}} 142 | \newcommand{\typename}[1]{{\bf #1}} 143 | \newcommand{\asvalue}[1]{{\bf #1}} 144 | 145 | 146 | % NAME RESOLUTION 147 | 148 | \newcommand{\packagepublic}[1]{\mathbf{Public}_{#1}} 149 | \newcommand{\packageinternal}[1]{\mathbf{Internal}_{#1}} 150 | \newcommand{\fileinternal}[1]{\mathbf{Program}} 151 | \newcommand{\classprivate}[1]{\mathbf{Private}_{#1}} 152 | \newcommand{\classprotected}[1]{\mathbf{Protected}_{\it #1}} 153 | \newcommand{\classprotectedstatic}[1]{\mathbf{StaticProtected}_{\it #1}} 154 | 155 | \newcommand{\pkg}{{\sf pkg}} 156 | \newcommand{\nsval}{{\sf nsval}} 157 | \newcommand{\xname}{{\sf xname}} 158 | \newcommand{\qname}{{\sf qname}} 159 | \newcommand{\id}{{\sf id}} 160 | \newcommand{\xquals}{{\sf XQuals}} 161 | \newcommand{\key}{{\sf key}} 162 | \newcommand{\str}{{\sf str}} 163 | \newcommand{\lexenv}{{\sf LexEnv}} 164 | \newcommand{\slot}{{\sf slot}} 165 | \newcommand{\mname}{{\sf mname}} 166 | \newcommand{\open}{{\sf Open}} 167 | \newcommand{\rname}{{\sf rname}} 168 | 169 | \newcommand{\func}[1]{\emph{#1}} 170 | 171 | 172 | % CONSTANT EVALUATION 173 | 174 | \newcommand{\val}{{\sf val}} 175 | \newcommand{\op}{{\sf op}} 176 | 177 | \newcommand{\name}{{\sf name}} 178 | \newcommand{\obj}{{\sf obj}} 179 | \newcommand{\rval}{{\sf ref}} 180 | \newcommand{\super}{{\sf super}} 181 | \newcommand{\new}{{\sf new}} 182 | \newcommand{\expr}{{\sf expr}} 183 | \newcommand{\dynenv}{{\sf DynEnv}} 184 | \newcommand{\ty}{{\sf ty}} 185 | \newcommand{\sig}{{\sf sig}} 186 | \newcommand{\body}{{\sf body}} 187 | \newcommand{\envrec}{{\sf EnvRec}} 188 | \newcommand{\envtbl}{{\sf EnvTbl}} 189 | 190 | \newcommand{\constenv}{\mathsf{ConstEnv}} 191 | 192 | \newcommand{\openavik}{\avik{}\color{RoyalBlue}} 193 | \newcommand{\closeavik}{\color{black}} 194 | 195 | \newcommand{\openjeff}{\jeff{}\color{RoyalBlue}} 196 | \newcommand{\closejeff}{\color{black}} 197 | 198 | % STATIC VERIFICATION 199 | 200 | \newcommand{\delete}{{\sf delete}} 201 | \newcommand{\typeof}{{\sf typeof}} 202 | \newcommand{\void}{{\sf void}} 203 | 204 | % EXPRESSIONS 205 | 206 | \newcommand{\excon}{{\sf ExCon}} 207 | \newcommand{\num}{{\sf num}} 208 | \newcommand{\lhsexpr}{{\sf lhsexpr}} 209 | \newcommand{\field}{{\sf field}} 210 | \newcommand{\info}{{\sf info}} 211 | 212 | 213 | % CODE 214 | \newcommand{\code}[1]{{\tt #1}} 215 | 216 | %OTHER 217 | \usepackage{listings} 218 | \lstset{numbers=none} 219 | -------------------------------------------------------------------------------- /as4wp/outlook.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{Upcoming Features} 16 | \label{upcoming} 17 | So far, we have just described the intended feature set of the first version of 18 | AS4. In this section we present additional features that we want to introduce as 19 | quickly as possible thereafter. 20 | 21 | Note that we cannot guarantee that these or any other features will appear in 22 | any particular form or order. Everything we have written from here on is to be 23 | considered as somewhat speculative. 24 | 25 | \subsection{The \code{Symbol} Class for String Interning} 26 | Instances of \code{String} objects are not interned, neither explicitly nor 27 | implicitly. If interning behavior is expected, the \code{Symbol} class must be 28 | used. 29 | 30 | \begin{verbatim} 31 | public restricted class Symbol extends String { 32 | /** 33 | * "Intern" a given string. 34 | * 35 | * 1. If the identical string is already in the global intenring table, 36 | * return it. 37 | * 2. Otherwise, if a string of equal content is already in the table, 38 | * return it. 39 | * 3. Otherwise, enter a copy of the string typed as \code{Symbol} 40 | * into the table, then return this resident unique representative 41 | * of all strings of equal content. 42 | * 43 | * The cost of the initial copying can quickly be amortized 44 | * when comparing symbols to each other by identity 45 | * instead of by equality as with non-interned strings. 46 | * 47 | * We assume that string interning is predominantly going to be used 48 | * for relatively short strings, which mitigates the initial interning cost. 49 | * 50 | * Explicit coercion of a value to \code{Symbol} (\code{value as Symbol}) 51 | * translates to a call to this method. 52 | * If necessary, this is preceded by implicit coercion to \code{String} 53 | * (\code{value as String as Symbol}). 54 | */ 55 | public static final function fromString(string :String) :Symbol; 56 | 57 | override public function equal(other :*):bool 58 | { 59 | return this.identical(other); 60 | } 61 | ... 62 | } 63 | \end{verbatim} 64 | All string literals are already \code{Symbol} instances. Additional 65 | \code{Symbol} instances can be produced from Strings by explicit coercion, 66 | as shown below or by direct calls to the above constructor. 67 | 68 | \begin{verbatim} 69 | function world():Symbol { return "World"; } 70 | 71 | let s1 :Symbol = "Hello"; // OK, because string literals are Symbols already 72 | let s2 :Symbol = "Hello" + world(); // Error, concatenating computed symbols produces a String 73 | 74 | let string1 :String = "Hello" + world(); 75 | let string2 :String = "Hello" + world(); 76 | print(string1 == string2); // true 77 | print(string1 === string2); // false 78 | 79 | let symbol1 :Symbol = string1 as Symbol; 80 | let symbol2 :Symbol = string2 as Symbol; 81 | print(symbol1 == symbol2); // true 82 | print(symbol1 === symbol2); // true 83 | \end{verbatim} 84 | 85 | \code{Symbol} extends \code{String}, but \code{String} is otherwise not 86 | extensible by user code without certain restrictions, which we explain in the 87 | following section. 88 | 89 | \subsection{Restricted Classes} 90 | Generalizing the concept behind class \code{Symbol}, we introduce the keyword 91 | \code{restricted} as class attribute. A {\em restricted} class can be extended 92 | by subclasses, but those must not declare any additional instance fields. 93 | Furthermore, every subclass of a restricted class must be a restricted class, 94 | too. 95 | 96 | Class \code{String} is a restricted class and class \code{Symbol} extends it 97 | (see above). 98 | 99 | Restricted classes can be used for encoding relevant invariants, which can thus 100 | be statically guaranteed by the type checker. That a string is guaranteed to be 101 | interned when typed as a \code{Symbol} is just one example. Other conceivable 102 | (user-defined) examples are: strings that comply with a certain lexical grammar 103 | (e.g. ``well-formed'' identifiers), lists that are assumed to be sorted, 104 | acyclical graphs, etc. Of course, the user has to be careful that the guaranteed 105 | invariants actually hold and cannot be broken by mutation of constituent 106 | variables. 107 | 108 | \subsection{Enumeration Types} 109 | In AS3, finite sets of discrete, enumerated values are customarily represented 110 | by string constants, which is a poor choice for various obvious reasons. 111 | Alternatively, one can use integer numbers, but this is not ideal either. There 112 | is a pattern that provides a more type-safe and comfortable encoding, but it 113 | requires a lot of boiler plate code and strict adherence to certain protocol. 114 | Example: 115 | \begin{verbatim} 116 | public final class RbgColor // AS3 enum pattern code: 117 | { 118 | private var _ordinal:int; 119 | 120 | public function get ordinal():String 121 | { 122 | return _ordinal; 123 | } 124 | 125 | private var _name:String; 126 | 127 | public function get name():String 128 | { 129 | return _name; 130 | } 131 | 132 | public function RgbColor(ordinal:int, name:String) 133 | { 134 | _ordinal = ordinal; 135 | _name = name 136 | } 137 | 138 | public static const RED:RgbColor = new RgbColor("red"); 139 | public static const GREEN:RgbColor = new RgbColor("green"); 140 | public static const BLUE:RgbColor = new RgbColor("blue"); 141 | } 142 | 143 | var myColor:RbgColor = someCondition() ? RgbColor.BLUE : someOtherColor(); 144 | ... 145 | switch (myColor.ordinal) 146 | { 147 | case RED: 148 | ... 149 | break; 150 | case GREEN: 151 | ... 152 | break; 153 | default: 154 | trace(myColor.name); 155 | break; 156 | } 157 | \end{verbatim} 158 | In AS4, this will soon be condensed as follows: 159 | \begin{verbatim} 160 | public enum Color { // AS4 code: 161 | RED, GREEN, BLUE 162 | } 163 | 164 | var myColor :RbgColor = someCondition() ? RgbColor.BLUE : someOtherColor(); 165 | ... 166 | switch (myColor) { 167 | case RED: 168 | ... 169 | break; 170 | case GREEN: 171 | ... 172 | break; 173 | default: 174 | trace(myColor); 175 | break; 176 | } 177 | \end{verbatim} 178 | 179 | There are more elaborate patterns for enum constants that have extra 180 | payload properties, and there are equally powerful syntactic enhancements in 181 | languages such as Haxe, C\# , Java, and others. We will take further inspiration 182 | from these and later extend AS4's enum capabilities accordingly as an extension 183 | of the above. 184 | 185 | \subsection{Abstract Classes and Methods} 186 | The new keyword \code{abstract} is used as an attribute for both classes and 187 | methods. An {\em abstract} class cannot be instantiated directly. Only its 188 | non-abstract subclasses can. 189 | 190 | An {\em abstract} method must not have a function body and it must not be 191 | native. The first non-abstract subclass of its declaring class must override it 192 | with a full method. 193 | 194 | Constructor functions cannot be abstract. 195 | 196 | A class that contains any abstract method must be declared as an abstract class. 197 | 198 | \subsection{Constructor, Method, and Function Overloading} 199 | AS4 will allow several different constructors with different parameter lists in 200 | the same class. And then, more generally, methods or functions with different 201 | function signatures can also have the same name, under certain conditions (to be specified later). This is also known 202 | as ad-hoc polymorphism, in that the compiler disambiguates direct calls to such 203 | methods or functions by discerning function signatures at compile time. 204 | 205 | \subsection{ActionScript Workers} 206 | We intend to reintroduce workers and to allow them in every deployement mode in 207 | AS4, not just in JIT-based deployments as in AS3. It is likely that we will 208 | update the Worker API to better leverage AS4 language features. 209 | 210 | \section{Future Features} 211 | \label{future} 212 | Last but not least, let us briefly look further ahead towards features that we 213 | have not fully designed yet, but that we are particularly keen on introducing to AS4. 214 | \begin{description} 215 | \item[Immutable Data Structure Types] 216 | \item[User-Defined Value Types] 217 | \item[Generics (Parameteric Polymorphism)] 218 | \item[Collection Library] 219 | \item[Module System] 220 | \item[Multi-Threading] 221 | \item[Nested Transactions on Versioned Data Structures] 222 | \item[Data Parallelism] 223 | \end{description} 224 | We will elaborate on these once we have completed designs in hand. 225 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | -------------------------------------------------------------------------------- /third-party/mathpartir/LICENSE: -------------------------------------------------------------------------------- 1 | GNU GENERAL PUBLIC LICENSE 2 | Version 2, June 1991 3 | 4 | Copyright (C) 1989, 1991 Free Software Foundation, Inc., 5 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA 6 | Everyone is permitted to copy and distribute verbatim copies 7 | of this license document, but changing it is not allowed. 8 | 9 | Preamble 10 | 11 | The licenses for most software are designed to take away your 12 | freedom to share and change it. By contrast, the GNU General Public 13 | License is intended to guarantee your freedom to share and change free 14 | software--to make sure the software is free for all its users. This 15 | General Public License applies to most of the Free Software 16 | Foundation's software and to any other program whose authors commit to 17 | using it. (Some other Free Software Foundation software is covered by 18 | the GNU Lesser General Public License instead.) You can apply it to 19 | your programs, too. 20 | 21 | When we speak of free software, we are referring to freedom, not 22 | price. Our General Public Licenses are designed to make sure that you 23 | have the freedom to distribute copies of free software (and charge for 24 | this service if you wish), that you receive source code or can get it 25 | if you want it, that you can change the software or use pieces of it 26 | in new free programs; and that you know you can do these things. 27 | 28 | To protect your rights, we need to make restrictions that forbid 29 | anyone to deny you these rights or to ask you to surrender the rights. 30 | These restrictions translate to certain responsibilities for you if you 31 | distribute copies of the software, or if you modify it. 32 | 33 | For example, if you distribute copies of such a program, whether 34 | gratis or for a fee, you must give the recipients all the rights that 35 | you have. You must make sure that they, too, receive or can get the 36 | source code. And you must show them these terms so they know their 37 | rights. 38 | 39 | We protect your rights with two steps: (1) copyright the software, and 40 | (2) offer you this license which gives you legal permission to copy, 41 | distribute and/or modify the software. 42 | 43 | Also, for each author's protection and ours, we want to make certain 44 | that everyone understands that there is no warranty for this free 45 | software. If the software is modified by someone else and passed on, we 46 | want its recipients to know that what they have is not the original, so 47 | that any problems introduced by others will not reflect on the original 48 | authors' reputations. 49 | 50 | Finally, any free program is threatened constantly by software 51 | patents. We wish to avoid the danger that redistributors of a free 52 | program will individually obtain patent licenses, in effect making the 53 | program proprietary. To prevent this, we have made it clear that any 54 | patent must be licensed for everyone's free use or not licensed at all. 55 | 56 | The precise terms and conditions for copying, distribution and 57 | modification follow. 58 | 59 | GNU GENERAL PUBLIC LICENSE 60 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 61 | 62 | 0. This License applies to any program or other work which contains 63 | a notice placed by the copyright holder saying it may be distributed 64 | under the terms of this General Public License. The "Program", below, 65 | refers to any such program or work, and a "work based on the Program" 66 | means either the Program or any derivative work under copyright law: 67 | that is to say, a work containing the Program or a portion of it, 68 | either verbatim or with modifications and/or translated into another 69 | language. (Hereinafter, translation is included without limitation in 70 | the term "modification".) Each licensee is addressed as "you". 71 | 72 | Activities other than copying, distribution and modification are not 73 | covered by this License; they are outside its scope. The act of 74 | running the Program is not restricted, and the output from the Program 75 | is covered only if its contents constitute a work based on the 76 | Program (independent of having been made by running the Program). 77 | Whether that is true depends on what the Program does. 78 | 79 | 1. You may copy and distribute verbatim copies of the Program's 80 | source code as you receive it, in any medium, provided that you 81 | conspicuously and appropriately publish on each copy an appropriate 82 | copyright notice and disclaimer of warranty; keep intact all the 83 | notices that refer to this License and to the absence of any warranty; 84 | and give any other recipients of the Program a copy of this License 85 | along with the Program. 86 | 87 | You may charge a fee for the physical act of transferring a copy, and 88 | you may at your option offer warranty protection in exchange for a fee. 89 | 90 | 2. You may modify your copy or copies of the Program or any portion 91 | of it, thus forming a work based on the Program, and copy and 92 | distribute such modifications or work under the terms of Section 1 93 | above, provided that you also meet all of these conditions: 94 | 95 | a) You must cause the modified files to carry prominent notices 96 | stating that you changed the files and the date of any change. 97 | 98 | b) You must cause any work that you distribute or publish, that in 99 | whole or in part contains or is derived from the Program or any 100 | part thereof, to be licensed as a whole at no charge to all third 101 | parties under the terms of this License. 102 | 103 | c) If the modified program normally reads commands interactively 104 | when run, you must cause it, when started running for such 105 | interactive use in the most ordinary way, to print or display an 106 | announcement including an appropriate copyright notice and a 107 | notice that there is no warranty (or else, saying that you provide 108 | a warranty) and that users may redistribute the program under 109 | these conditions, and telling the user how to view a copy of this 110 | License. (Exception: if the Program itself is interactive but 111 | does not normally print such an announcement, your work based on 112 | the Program is not required to print an announcement.) 113 | 114 | These requirements apply to the modified work as a whole. If 115 | identifiable sections of that work are not derived from the Program, 116 | and can be reasonably considered independent and separate works in 117 | themselves, then this License, and its terms, do not apply to those 118 | sections when you distribute them as separate works. But when you 119 | distribute the same sections as part of a whole which is a work based 120 | on the Program, the distribution of the whole must be on the terms of 121 | this License, whose permissions for other licensees extend to the 122 | entire whole, and thus to each and every part regardless of who wrote it. 123 | 124 | Thus, it is not the intent of this section to claim rights or contest 125 | your rights to work written entirely by you; rather, the intent is to 126 | exercise the right to control the distribution of derivative or 127 | collective works based on the Program. 128 | 129 | In addition, mere aggregation of another work not based on the Program 130 | with the Program (or with a work based on the Program) on a volume of 131 | a storage or distribution medium does not bring the other work under 132 | the scope of this License. 133 | 134 | 3. You may copy and distribute the Program (or a work based on it, 135 | under Section 2) in object code or executable form under the terms of 136 | Sections 1 and 2 above provided that you also do one of the following: 137 | 138 | a) Accompany it with the complete corresponding machine-readable 139 | source code, which must be distributed under the terms of Sections 140 | 1 and 2 above on a medium customarily used for software interchange; or, 141 | 142 | b) Accompany it with a written offer, valid for at least three 143 | years, to give any third party, for a charge no more than your 144 | cost of physically performing source distribution, a complete 145 | machine-readable copy of the corresponding source code, to be 146 | distributed under the terms of Sections 1 and 2 above on a medium 147 | customarily used for software interchange; or, 148 | 149 | c) Accompany it with the information you received as to the offer 150 | to distribute corresponding source code. (This alternative is 151 | allowed only for noncommercial distribution and only if you 152 | received the program in object code or executable form with such 153 | an offer, in accord with Subsection b above.) 154 | 155 | The source code for a work means the preferred form of the work for 156 | making modifications to it. For an executable work, complete source 157 | code means all the source code for all modules it contains, plus any 158 | associated interface definition files, plus the scripts used to 159 | control compilation and installation of the executable. However, as a 160 | special exception, the source code distributed need not include 161 | anything that is normally distributed (in either source or binary 162 | form) with the major components (compiler, kernel, and so on) of the 163 | operating system on which the executable runs, unless that component 164 | itself accompanies the executable. 165 | 166 | If distribution of executable or object code is made by offering 167 | access to copy from a designated place, then offering equivalent 168 | access to copy the source code from the same place counts as 169 | distribution of the source code, even though third parties are not 170 | compelled to copy the source along with the object code. 171 | 172 | 4. You may not copy, modify, sublicense, or distribute the Program 173 | except as expressly provided under this License. Any attempt 174 | otherwise to copy, modify, sublicense or distribute the Program is 175 | void, and will automatically terminate your rights under this License. 176 | However, parties who have received copies, or rights, from you under 177 | this License will not have their licenses terminated so long as such 178 | parties remain in full compliance. 179 | 180 | 5. You are not required to accept this License, since you have not 181 | signed it. However, nothing else grants you permission to modify or 182 | distribute the Program or its derivative works. These actions are 183 | prohibited by law if you do not accept this License. Therefore, by 184 | modifying or distributing the Program (or any work based on the 185 | Program), you indicate your acceptance of this License to do so, and 186 | all its terms and conditions for copying, distributing or modifying 187 | the Program or works based on it. 188 | 189 | 6. Each time you redistribute the Program (or any work based on the 190 | Program), the recipient automatically receives a license from the 191 | original licensor to copy, distribute or modify the Program subject to 192 | these terms and conditions. You may not impose any further 193 | restrictions on the recipients' exercise of the rights granted herein. 194 | You are not responsible for enforcing compliance by third parties to 195 | this License. 196 | 197 | 7. If, as a consequence of a court judgment or allegation of patent 198 | infringement or for any other reason (not limited to patent issues), 199 | conditions are imposed on you (whether by court order, agreement or 200 | otherwise) that contradict the conditions of this License, they do not 201 | excuse you from the conditions of this License. If you cannot 202 | distribute so as to satisfy simultaneously your obligations under this 203 | License and any other pertinent obligations, then as a consequence you 204 | may not distribute the Program at all. For example, if a patent 205 | license would not permit royalty-free redistribution of the Program by 206 | all those who receive copies directly or indirectly through you, then 207 | the only way you could satisfy both it and this License would be to 208 | refrain entirely from distribution of the Program. 209 | 210 | If any portion of this section is held invalid or unenforceable under 211 | any particular circumstance, the balance of the section is intended to 212 | apply and the section as a whole is intended to apply in other 213 | circumstances. 214 | 215 | It is not the purpose of this section to induce you to infringe any 216 | patents or other property right claims or to contest validity of any 217 | such claims; this section has the sole purpose of protecting the 218 | integrity of the free software distribution system, which is 219 | implemented by public license practices. Many people have made 220 | generous contributions to the wide range of software distributed 221 | through that system in reliance on consistent application of that 222 | system; it is up to the author/donor to decide if he or she is willing 223 | to distribute software through any other system and a licensee cannot 224 | impose that choice. 225 | 226 | This section is intended to make thoroughly clear what is believed to 227 | be a consequence of the rest of this License. 228 | 229 | 8. If the distribution and/or use of the Program is restricted in 230 | certain countries either by patents or by copyrighted interfaces, the 231 | original copyright holder who places the Program under this License 232 | may add an explicit geographical distribution limitation excluding 233 | those countries, so that distribution is permitted only in or among 234 | countries not thus excluded. In such case, this License incorporates 235 | the limitation as if written in the body of this License. 236 | 237 | 9. The Free Software Foundation may publish revised and/or new versions 238 | of the General Public License from time to time. Such new versions will 239 | be similar in spirit to the present version, but may differ in detail to 240 | address new problems or concerns. 241 | 242 | Each version is given a distinguishing version number. If the Program 243 | specifies a version number of this License which applies to it and "any 244 | later version", you have the option of following the terms and conditions 245 | either of that version or of any later version published by the Free 246 | Software Foundation. If the Program does not specify a version number of 247 | this License, you may choose any version ever published by the Free Software 248 | Foundation. 249 | 250 | 10. If you wish to incorporate parts of the Program into other free 251 | programs whose distribution conditions are different, write to the author 252 | to ask for permission. For software which is copyrighted by the Free 253 | Software Foundation, write to the Free Software Foundation; we sometimes 254 | make exceptions for this. Our decision will be guided by the two goals 255 | of preserving the free status of all derivatives of our free software and 256 | of promoting the sharing and reuse of software generally. 257 | 258 | NO WARRANTY 259 | 260 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY 261 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN 262 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES 263 | PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED 264 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 265 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS 266 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 267 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, 268 | REPAIR OR CORRECTION. 269 | 270 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 271 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR 272 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, 273 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING 274 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED 275 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY 276 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 277 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE 278 | POSSIBILITY OF SUCH DAMAGES. 279 | 280 | END OF TERMS AND CONDITIONS 281 | 282 | How to Apply These Terms to Your New Programs 283 | 284 | If you develop a new program, and you want it to be of the greatest 285 | possible use to the public, the best way to achieve this is to make it 286 | free software which everyone can redistribute and change under these terms. 287 | 288 | To do so, attach the following notices to the program. It is safest 289 | to attach them to the start of each source file to most effectively 290 | convey the exclusion of warranty; and each file should have at least 291 | the "copyright" line and a pointer to where the full notice is found. 292 | 293 | 294 | Copyright (C) 295 | 296 | This program is free software; you can redistribute it and/or modify 297 | it under the terms of the GNU General Public License as published by 298 | the Free Software Foundation; either version 2 of the License, or 299 | (at your option) any later version. 300 | 301 | This program is distributed in the hope that it will be useful, 302 | but WITHOUT ANY WARRANTY; without even the implied warranty of 303 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 304 | GNU General Public License for more details. 305 | 306 | You should have received a copy of the GNU General Public License along 307 | with this program; if not, write to the Free Software Foundation, Inc., 308 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 309 | 310 | Also add information on how to contact you by electronic and paper mail. 311 | 312 | If the program is interactive, make it output a short notice like this 313 | when it starts in an interactive mode: 314 | 315 | Gnomovision version 69, Copyright (C) year name of author 316 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 317 | This is free software, and you are welcome to redistribute it 318 | under certain conditions; type `show c' for details. 319 | 320 | The hypothetical commands `show w' and `show c' should show the appropriate 321 | parts of the General Public License. Of course, the commands you use may 322 | be called something other than `show w' and `show c'; they could even be 323 | mouse-clicks or menu items--whatever suits your program. 324 | 325 | You should also get your employer (if you work as a programmer) or your 326 | school, if any, to sign a "copyright disclaimer" for the program, if 327 | necessary. Here is a sample; alter the names: 328 | 329 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program 330 | `Gnomovision' (which makes passes at compilers) written by James Hacker. 331 | 332 | , 1 April 1989 333 | Ty Coon, President of Vice 334 | 335 | This General Public License does not permit incorporating your program into 336 | proprietary programs. If your program is a subroutine library, you may 337 | consider it more useful to permit linking proprietary applications with the 338 | library. If this is what you want to do, use the GNU Lesser General 339 | Public License instead of this License. 340 | -------------------------------------------------------------------------------- /as4wp/intro.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{Introduction and Motivation} 16 | The ActionScript\textsuperscript{\textregistered} language has not changed since 17 | 2006. At the time of this writing it is still in the same version 3 without any 18 | significant updates. 19 | But the demands on the Adobe\textsuperscript{\textregistered} 20 | Flash\textsuperscript{\textregistered} platform and on its language have 21 | shifted. We now introduce a new version of ActionScript that is oriented at the 22 | requirements of larger and more performance-critical applications across a wider 23 | range of deployment scenarios than anticipated for its predecessor: ActionScript 24 | 4. 25 | 26 | The Flash platform has a rich ecosystem into which it deploys programs in a 27 | variety of forms: packaged applications with a captive runtime, loaded 28 | applications on a standalone Flash Player or on a full Adobe 29 | AIR\textsuperscript{\textregistered} installation, dynamically loaded 30 | applications in web browser plugins. Providing a true cross-platform developer 31 | experience across these different scenarios as well as the related ubiquity are 32 | primary attractions that give the Flash platform a great competitive edge. 33 | 34 | In the following we analyze the prospects of each deployment mode and how it 35 | sets the stage for our language design. Next we derive guidance from major 36 | technological trends and from our focus audience: game developers. 37 | Then we summarize all of the above in high level guidelines for our language 38 | design. 39 | 40 | \subsection{Smartphones: Apps, Resource Constraints} 41 | The dominant distribution form of programs on smartphones is ``apps'', and the 42 | availability of Flash Player in mobile browsers is severely limited. Apps are 43 | statically compiled and even statically linked. This means that AS4 needs to be 44 | well-suited for static compilation and cannot rely on dynamic optimizations to 45 | achieve acceptable performance. This requirement is exacerbated by smartphones 46 | having relatively weak compute power. Furthermore, power consumption is a major 47 | concern and code performance improvement is a common prescription for this, 48 | since quicker execution reduces the amount of time any given stretch of code 49 | requires power. 50 | 51 | For app deployment, we should continue to offer a form of native extensions that 52 | can employ functionality specific to one native platform in a non-portable way. 53 | 54 | \subsection{Tablets: Middle Ground} 55 | Initially, tablets are like a large smartphone without a phone function, or more 56 | precisely like a large iPod Touch. So they emphasize {\em apps} over {\em web} 57 | just like smartphones. But we have to be prepared for {\em web} also. Quite 58 | possibly, tablets will supplant large parts of PC install base, and then this will perpetuate the 59 | requirements we are facing now for desktops. 60 | 61 | Already, we are seeing tablets with physical keyboards, which makes them a lot 62 | more similar to laptops. And for people who enjoy virtual keyboards more than 63 | physical ones, one can argue that tablets have been similar to laptops already. 64 | So either way, the result is pretty much equivalent to a laptop with touch 65 | input. And touch input is just arriving on laptops and even regular desktops, 66 | too. In other words, the differences between tablet, laptop, and desktop are 67 | blurring. As a result of this, we will continue to face devices with PC-class 68 | capabilities, in whatever physical shape, and this will remain relevant. 69 | 70 | The real question is what artificial restrictions will be imposed on these 71 | platforms regarding runtime deployment, application code deployment, and dynamic 72 | code generation. Recently, we have experienced a trend towards more close 73 | control. Furthermore, Flash Player deployment is also constrained by our own 74 | capacity to conduct and support porting efforts, especially in the relatively fragmented 75 | mobile space, including tablets. However, for all we know, there will continue 76 | to be at least some tablets that admit Flash Player to browsers. 77 | Since it is hard to predict market share and constraints concerning all platform owners 78 | for extended periods of time, we must stay nimble. This means keeping support for 79 | JIT deployments enabled, even for tablets. 80 | 81 | On the other hand, there are more and more cheaper, low-end tablets. This 82 | perpetuates the alignment with smart phones. Apps are here to stay as 83 | deployment form as well. 84 | 85 | So unsurprisingly, we see tablets positioned in the middle between smartphones 86 | and desktop, requiring both AOT and JIT deployment. Furthermore, the performance 87 | arguments made in reference to smartphones apply typically also to tablets, 88 | though lessened by their relatively larger compute and battery capacity. 89 | 90 | \subsection{Desktop: High End Clients} 91 | No matter how successful tablets become, desktops stay relevant. Many uses are 92 | better served by their larger form factor and their superior compute power and 93 | being mobile is not always required. Furthermore, the monetization of software 94 | and services on mobile devices is relatively weak, even though the cross-over 95 | point for mobile device numbers trumping PC numbers has been reached. 96 | 97 | By definition, the desktop device class carries the high end for compute clients 98 | (including workstations). There did not use to be a choice between PCs and 99 | mobile devices. Now that there is, the higher investment in a PC implies 100 | indications concerning the user's objectives. Why would anyone choose a PC over 101 | a tablet or smartphone? 102 | \begin{itemize} 103 | \item Performance 104 | \item Screen real estate 105 | \item Memory 106 | \item Storage and storage bandwidth 107 | \item Network bandwidth 108 | \end{itemize} 109 | 110 | Today, the deployment of Flash Player is almost unrestricted on desktops. The 111 | plugin is virtually ubiquitous. And it requires a JIT to perform well. This 112 | gives us the opportunity to put features into our language that provide the 113 | ultimate performance experience, fully exploiting dynamic optimization. 114 | 115 | For JavaScript, and also for ActionScript until now, dynamic compilation is 116 | first of all a compensating measure for inherent performance impediments. 117 | Aiming to eventually make performance a competitive differentiator for 118 | ActionScript, we now prefer to drive performance from a language design position 119 | that lets performance optimizations take off from higher ground. 120 | 121 | Today's desktops have such abundance of memory that there is no question that we 122 | have to support 64-bit computing. This has to be taken into account for mass 123 | data types in ActionScript. 124 | 125 | \subsection{Servers: Outlook} 126 | For various reasons, the Flash platform is a client-centric technology without 127 | significant deployment on servers. Among those reasons, insufficient performance, the lack 128 | of concurrency, and the resulting poor hardware utilization have to be seen as 129 | major impediments. It is expected that these downsides will be mitigated and 130 | eventually overcome by our efforts on the client side. At least from a language 131 | and VM perspective there should then be no barrier to running (large) AS4 132 | applications on servers. Besides, this also applies to server-side AS4 133 | in cloud computing. 134 | 135 | If and when AS4 will be running well on servers, the same arguments that are 136 | made today on desktops wrt. performance, memory, storage, and bandwidth will 137 | apply, only more so. 138 | We can count on 64-bit and multi-core requirements. Furthermore, our language 139 | design should be on a trajectory that can lead to efficient expression of distributed 140 | programs. 141 | 142 | \subsection{Multi-Core and Many-Core} 143 | Mobile devices increasingly feature multi-core CPUs and on desktops they are 144 | already common place. With today's single-threaded ActionScript or even with AS 145 | ``workers", this means unused hardware, poor utilization, categorically 146 | restricted performance. Furthermore, power efficiency is crucial on mobile 147 | devices and performance is a key driver for power savings. Combining these two 148 | observations, we cannot afford to leave the available hardware concurrency 149 | presented by multi-core CPUs untapped. 150 | 151 | With frameworks like Stage3D and Starling, Flash Player is successful in 152 | harnessing the power of GPUs for rendering and making it available in a cross-platform fashion. 153 | But less graphics-oriented compute tasks are underserved. We need to tap more 154 | into the available parallelism on GPUs and GPGPUs to drive performance beyond 155 | multi-core capacity. 156 | 157 | We are working towards integrating concurrent/parallel programming seamlessly 158 | into ActionScript. This already affects earlier features of AS4. We are strongly 159 | motivated to facilitate functional programming style. In particular, this 160 | includes suppressing mutability of values where possible, i.e. wherever 161 | tolerable. 162 | 163 | \subsection{HTML5: Redividing the Application Space} 164 | HTML, CSS, and JavaScript have become more expressive and performant and capable 165 | of fulfilling roles that used to be covered by Flash Player alone. Many 166 | analysts, bloggers and article commenters claim that the Flash platform will or 167 | at least should be displaced {\em completely}. Yet 168 | there is no compelling \code{technical} reason that reduces the remaining realm of the Flash platform 169 | overwhelmingly, and it can grow without serious challenge in areas where 170 | HTML/JavaScript will never be able to catch up. 171 | JavaScript programming has at least these limitations: 172 | \begin{itemize} 173 | \item It scales poorly in program size and in team size. 174 | \item IDE support is hindered by dynamic typing. 175 | \item Debugging effort is multiplied by the lack of static checking. 176 | \item The achievable performance ceiling is limited by dynamic features. 177 | \item It is ill-suited for static compilation and thus JavaScript apps 178 | often cannot be competitive with native apps. 179 | \item It is all too easy to write badly performing code, to fall into 180 | performance anti patterns. 181 | \item Innovation progress is throttled by standardization. 182 | \item Its implementation is fragmented and there are economic incentives for 183 | its standardization members and for its implementors to fragment it as well 184 | as to reconcile it. At the very least, we can expect its fragmentation to 185 | oscillate. 186 | \end{itemize} 187 | Despite all this, HTML5/JavaScript is here to stay. One cannot not serve the 188 | Web! Here it is our task to provide a superior alternative where HTML5/JavaScript is 189 | bound to lack. This amounts to a vast space, not just a niche. 190 | The Flash platform should be able to continue its role as technological trail 191 | blazer. 192 | 193 | There is still a large overlap in the application space between HTML5 194 | and the Flash platform and we do not expect it to shrink away entirely. We 195 | should be prepared to continue seeing Flash technologies used for general 196 | purpose web programming, ads, banners and so on. We should therefore keep a certain amount of dynamic features to 197 | interoperate with web technologies and to provide smooth onramping of web programmers to 198 | ActionScript 4. The latter can also be facilitated with gradual 199 | typing and type inference. 200 | 201 | However, even though we position Flash technologies as a general purpose 202 | programming platform, including web programming, our focus of attention has 203 | moved on to the following topic. 204 | 205 | \subsection{Game Development} 206 | 207 | Gaming is the ideal technological focus area for further developing the Flash 208 | platform. 209 | \begin{itemize} 210 | \item The Flash platform already enjoys a large user base in web and app 211 | gaming. 212 | \item This is a fast growing, revenue rich product area. 213 | \item Adobe as a creative design company must play in this space, since it is 214 | the pinnacle of creative design, posing the greatest challenges. 215 | \item The requirements for game programming subsume those of most other disciplines. 216 | If we master gaming, then the technology developed for it will be 217 | applicable to virtually everything else. This can be seen as 218 | trickle down tech transfer from the most demanding area of all. 219 | \item Game developers are early adopters, more forgiving wrt. initial problems 220 | in newly developed offerings than most other communities. 221 | \end{itemize} 222 | 223 | Besides media asset creation, game programming can generally be categorized into 224 | these main areas: 225 | \begin{center} 226 | \begin{tabular}{ | l | l | l |} 227 | \hline 228 | {\em Category} & {\em Example Tasks} & {\em Typical Programming Styles} \\ 229 | \hline Game Logic & player actions, story line/script, UI, events & 230 | object-oriented, imperative \\ 231 | \hline Numeric computation & physics, strategy, constraint 232 | solving & functional, imperative \\ 233 | \hline Rendering & 3D/2D shading, sprites, video, images, effects & declarative, 234 | constructive 235 | \\ 236 | \hline Communication & network / distributed programming & object-oriented, 237 | reactive 238 | \\ 239 | \hline 240 | \end{tabular} 241 | \end{center} 242 | In the short term, and in the scope of this text, we concentrate on the former 243 | two of these. 244 | 245 | \subsubsection{Social Gaming} 246 | Social games are booming. The market for them has become very competitive. The 247 | effort going into each individual game development is high. Team sizes often 248 | reach into several dozen developers, not rarely to more than a hundred. 249 | This clearly is programming in the large, which could benefit greatly from 250 | better language and tool support. 251 | 252 | Frame rates convert into dollars. Here once again, improving Flash 253 | Player performance is key. 254 | 255 | \subsubsection{AAA Gaming} 256 | 257 | Some game engines run thousands of different tasks in a quasi-concurrent 258 | fashion. To allow developers to map these directly to threads way beyond the 259 | point of oversubscribing multi-core parallelism, we aim to offer a two-level 260 | thread model in a later version of ActionScript. 261 | 262 | We also need to leverage all available hardware for numeric computation, 263 | whereas rendering is being served sufficiently well with API approaches. 264 | 265 | ActionScript game code can be mixed with code written in other languages 266 | such as C++ when compiling the latter with FlasCC. 267 | 268 | \subsection{Conclusions and Goals} 269 | From the above, we gather these requirements: 270 | \begin{description} 271 | \item[Cross-platform:] Cross-platform development remains the main attractor, 272 | even though the dynamics of device and OS regulations 273 | have shifted our deployment modes in recent year as follows. 274 | \item [Both JIT and AOT:] The range of application deployment targets clearly 275 | indicates that both JIT and AOT are here to stay for the foreseeable future and 276 | that we should stay nimble in that regard anyway. This means that if 277 | AS4 is supposed to be a high performance language, it needs to be shaped so that 278 | great performance is possible without relying on dynamic optimizations. 279 | \item[Maximum performance:] In order not only to catch up with competitors, 280 | but to make performance a defendable differentiator for AS4, we have to design 281 | it so that virtually nothing is in the way of performance maximization. 282 | Especially under the aspect of AOT compilation this means that static typing 283 | has to be the default setting and that it has to be absolutely stringent 284 | wherever possible unless the 285 | developer opts out explicitly (by using the \code{*} type). In general, we favor making 286 | non-dynamic features fast over whatever the consequences for dynamic features 287 | are. We also arrange the type hierarchy so that the source compiler can arrange 288 | autoboxing. Operations on primitive types do not have inherent control 289 | flow (when statically typed). Furthermore we introduce fixed-length 290 | arrays, and we plan for multi-dimensional arrays with VM-determined 291 | data layout. 292 | \item[Machine types:] Primitive data types must translate directly to hardware 293 | operand types to provide maximum performance, but also to facilitate 294 | mapping C data types to ActionScript via FlasCC, and to enable us to 295 | develop a foreign interface. The latter will eventually make native extensions 296 | simpler to write and better performing, and it is intended to greatly simplify 297 | the implementation of the Flash Platform itself. To these ends, we should also 298 | offer user-defined value types that aggregate primitive types. 299 | \item[Hardare utilization:] We carefully design the first version of AS4 300 | for the later introduction of high-performance multi-threading and parallelism features, 301 | since offering these is necessary to provide competitive hardware 302 | utilization. 303 | \item[Programming in the large:] Competitive pressures, in particular in game 304 | development, drive our developers towards larger efforts that require more 305 | coordination and more quality frontloading. This also enforces our choice to 306 | support static strong typing. Furthermore, our core language design must be 307 | suitable for the introduction of generics (parametric polymorphic typing) in the 308 | future. This will enhance expressiveness while maintaining static typing. 309 | \item[Both object-oriented and functional:] Large program organization 310 | benefits from object-oriented style and a variety of well-known related 311 | patterns. Yet we want to promote functional programming style for 312 | more algorithmic program parts, especially when these involve concurrency. 313 | Reconciling the two styles, we aim at making object-oriented program parts more amenable to functional programing. 314 | Concretely this dictates giving immutability preference over mutability 315 | whenever possible. To this end we introduce two-phase constructors, which 316 | facilitate declaring and guaranteeing truly constant object fields, virtually 317 | without any loss of generality wrt. what constructors can express. Besides this 318 | feature, we are generally promoting immutability throughout the language to make 319 | developers more accustomed to paying attention to it. For example, function parameters are by default 320 | immutable in AS4. 321 | \item[Small and large memory:] We can future-proof certain mass data types like 322 | arrays and strings by allowing them to range over 64 bits while at the same time 323 | allowing the VM to choose a space-efficient representation on constrained 324 | devices. However, we should also offer the usual 32-bit variants, since small 325 | arrays and strings are common. 326 | \item[Supplemental dynamic features:] Every static type system has its limits 327 | wrt. expressiveness. We should supplement it with select dynamic features and a 328 | comprehensive reflection API. But we must be careful to not compromise our other 329 | goals by doing so. 330 | \item[Type inference:] Static typing does not always require stating types explicitly. The most 331 | suitable types that one might have written can more often than not be discovered 332 | by the compiler and inserted automatically. This mitigates the typing effort and 333 | visual impact caused by static typing compared to dynamic typing. However, type 334 | inference can also be useful even in dynamically typed code contexts, providing opportunistic 335 | performance improvements. 336 | \end{description} 337 | 338 | Adobe is not only going to update the ActionScript language but also going 339 | to renovate the libraries in Flash Player, moving from V11 versions to V12. In 340 | both cases, there will be a compatibility break that affects the source code level as well as the binary level. 341 | AS3 will not run on V12 and AS4 will not run on V11. AS4 and V12 will be a fresh new reinvention of the Flash 342 | platform, not just an incremental upgrade.\footnote{AS3 and V11 content will continue to run in Flash Player, which will dynamically 343 | detect which runtime version to launch.} 344 | 345 | However, both the AS4 language and the V12 APIs will look very similar and familiar to existing developers. 346 | This is of course intentional, to facilitate migration to our new platform version. Yet we believe that given its 347 | more concise and disciplined design, AS4 will be easier to learn than AS3 for many of those who will come to our 348 | platform as new developers. 349 | 350 | 351 | \subsection{Overview} 352 | To fulfil all of the above goals, it became necessary to drop some features from AS3. These are 353 | discussed in the next section. Other features, while kept, have been modified as explained in 354 | section~\ref{changes}. In principle, significant portions of AS3 code can be ported to AS4 given this knowledge alone. 355 | But we are aware that this is temporarily limited by some valued AS3 features having been removed without replacement. 356 | Eventually, there will be powerful substitutes that fit in well with the new language. 357 | 358 | The following sections present new features in AS4. We first describe those designated for an initial release 359 | (section~\ref{new}), then we sketch the next wave (section~\ref{upcoming}). Finally, we give an outlook on features 360 | (section~\ref{future}) that are further out in our schedule. This is to provide a first impression of the overall 361 | direction and significance of the AS4/V12 platform. 362 | 363 | The appendix contains implementation notes (section~\ref{impl}) and a listing of base classes and interfaces 364 | (\ref{base}), which includes core classes in the type hierarchy as well as a new reflection API. 365 | 366 | In the remainder of this text we assume that the reader is already familiar with 367 | ActionScript 3. 368 | -------------------------------------------------------------------------------- /as4wp/dropped.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{Dropped Features Relative to ActionScript 3} 16 | \label{dropped} 17 | In this section we list features of AS3 that are being 18 | dropped in AS4, motivate why they are being dropped, and suggest 19 | ways of porting AS3 code that relies on those features to AS4. 20 | 21 | \subsection{The \code{with} Construct} 22 | 23 | AS3 supports \code{with} statements \`a la ECMAScript 3. Such 24 | statements introduce dynamic scoping in the language, as the following example shows. 25 | 26 | \begin{minipage}{\linewidth} 27 | \begin{verbatim} 28 | function f(o:Object) { 29 | var x:int = 6; // declares local variable x 30 | var y:int = 42; 31 | with(o) { 32 | x = 7; // updates o.x instead of x 33 | y = 0; 34 | } 35 | print(x, o.x); // 6, 7 36 | print(y); // 0 37 | } 38 | f({x : 6}); // passes an object with property x 39 | \end{verbatim} 40 | \end{minipage} 41 | 42 | Dynamic scoping has several drawbacks: 43 | 44 | \begin{itemize} 45 | 46 | \item Dynamic scoping is expensive to implement, since it requires 47 | maintaining a chain of run-time objects (a.k.a. scope chain) for 48 | resolving lexical references. 49 | 50 | In particular, dynamic scoping makes function closures (run-time representations of functions that are passed by 51 | value) heavyweight, since a function closure must capture the scope chain that is in effect 52 | at the point of function definition. 53 | 54 | But closures are often used to pass handlers in 55 | event-based programming. 56 | 57 | Furthermore, going forward, we want to encourage people to use closures 58 | (as part of a move to parallel programming using maps, for example). 59 | 60 | Finally, lightweight closures are required to implement our new object 61 | initialization protocol (see section~\ref{construct2}). 62 | 63 | \item Dynamic scoping also causes the compiler to ignore static errors, thereby 64 | requiring dynamic checking to guard assignments to variables, to maintain type 65 | safety, and therefore security, at run-time. 66 | In other words, if we cannot ensure that a variable of type $T$ will always hold 67 | values of type $T$, then the dynamic compiler / VM cannot safely allocate space 68 | for the variable based on $T$ without guarding assignments to that variable; 69 | such guards potentially degrade performance. 70 | 71 | \end{itemize} 72 | 73 | It is instructive to note that for similar reasons, EcmaScript 5 strict mode 74 | makes it a syntax error to use \code{with} statements. 75 | 76 | The main benefit of dropping \code{with} statements is that we recover 77 | lexical scoping, which enables compile-time optimizations. 78 | 79 | \begin{itemize} 80 | \item Lexical scoping is efficiently implementable by relying on a flat, compile-time map over 81 | variables (where variables declared in inner scopes shadow variables 82 | declared in outer scopes). This considerably simplifies and improves 83 | the performance of name lookup. 84 | 85 | \item Lexical scoping allows the compiler to eliminate dynamic checking on 86 | assignment to variables in scope. This is a big performance 87 | win. In fact, it is unfortunate that statically typed AS3 programs 88 | do not enjoy this benefit, since this performance win is part of the promise of 89 | static typing in general. Indeed the primary goal of static typing is 90 | proving, at compile-time, that dynamic typechecking is redundant: 91 | statically typed programs do not violate type safety. 92 | 93 | \end{itemize} 94 | 95 | A slow, but mostly functional hack for porting code that relies on 96 | \code{with} statements is as follows. Code inside a 97 | \code{with} block for object \code{o} can be transformed so that 98 | every lexical reference \code{x} is rewritten to a conditional that checks 99 | whether \code{x} can be found in \code{o} and branches to either 100 | \code{o.x} or \code{x}. Essentially, this amounts to inlining the 101 | lookup logic inside \code{with} statements. 102 | 103 | Note that the keyword \code{with} is no longer required, although we may want to 104 | reserve it for future repurposing. 105 | 106 | 107 | \subsection{Namespaces and E4X} 108 | 109 | In AS3, namespaces enable a form of dynamic overloading, where different functions 110 | with the same name may be defined in different namespaces and called 111 | by supplying the namespaces at run time. Namespaces were introduced as 112 | part of the EcmaScript 4 effort, which was eventually abandoned (so 113 | that namespaces never made it into other JavaScript implementations). 114 | 115 | Namespaces unify a lot of concepts in AS3: packages, access 116 | control modifiers, API versioning. However, arguably all of those 117 | concepts can be readily implemented without namespaces. At the same time, there do not seem to be existing 118 | applications that exploit the full expressive power of namespaces: for 119 | example, namespaces could provide a powerful mechanism to do 120 | capability-based programming, but no such framework seems to be in use by 121 | the AS3 developer community. As such, namespaces seem like ``a hammer 122 | looking for a nail'' that everybody pays for but only few, if at all, use. 123 | 124 | The design and implementation of namespaces in AS3 suffer from many problems: 125 | 126 | \begin{itemize} 127 | 128 | \item When combined 129 | with static binding of function calls to function definitions based on 130 | static types, namespaces have several unintuitive implications, as the 131 | following example shows. 132 | 133 | 134 | \begin{verbatim} 135 | namespace N1; namespace N2; 136 | class A { 137 | N1 function f() { print("in A"); } 138 | } 139 | class B extends A { 140 | N2 function f() { print("in B"); } 141 | } 142 | 143 | use namespace N1; use namespace N2; 144 | // adds {N1,N2} to the set of possible qualifiers for every lexical reference 145 | 146 | var b:B = new B(); 147 | b.N2::f(); // in B 148 | b.f(); // in B 149 | // desugars to b.{N1,N2}::f(), which early binds to b.N2::f() because b:B 150 | 151 | var a:A = b; 152 | a.N1::f(); // in A 153 | a.f(); // in A 154 | // desugars to a.{N1,N2}::f(), which early binds to a.N1::f() because a:A 155 | 156 | var c:* = ... ? a : b; 157 | c.f(); // in B 158 | // desugars to c.{N1,N2}::f(), which late binds to c.N2::f() because c is a B-object 159 | // this means that we cannot infer c:A 160 | \end{verbatim} 161 | 162 | Thus, namespaces preclude type inference for optimization: 163 | any precision lost when doing type inference may cause semantic 164 | unsoundness, i.e., may change the behavior of the 165 | program. Unfortunately, in an object-oriented language, subtyping 166 | is a key characteristic, so losing precision via subtyping is common and in fact 167 | desirable: it is not reasonable to require tracking exact types. 168 | 169 | \item Furthermore, namespaces make references heavyweight: every reference consists of 170 | not just an identifier but, in the worst case, a set of namespaces 171 | that need to be resolved at run time; such references may be ambiguous 172 | (i.e., they may resolve to different definitions), and throwing errors 173 | when they are ambiguous requires \emph{all} definitions that possibly 174 | match to be 175 | considered during name resolution (as opposed to just finding 176 | \emph{some} definition that matches). 177 | 178 | \item Finally, it is painful to specify, understand, and implement 179 | namespaces. For example, it is tedious to work out what happens when 180 | namespaces are themselves defined in namespaces, which are in turn ``opened'' 181 | in some order (via \code{use namespace'}; see the AS3 language specification 182 | for details on this and other issues. Not surprisingly, the AS3 compiler has 183 | numerous bugs around namespaces. Furthermore, the VM has several notions of 184 | names, including multinames and run-time qualified names, that add subcases to 185 | several core bytecodes; see the AVM2 overview for details. (In fact, it is a 186 | fair claim that almost nobody inside Adobe enjoys a full understanding of the 187 | internals of namespaces, as evident from numerous misunderstandings that keep 188 | coming up in various discussions on the topic: a situation that is untenable 189 | going forward.) 190 | \end{itemize} 191 | 192 | The main benefits of dropping namespaces are: 193 | 194 | \begin{itemize} 195 | \item huge reduction in complexity in the language specification and 196 | the VM implementation; 197 | \item performance improvements (both in time and in space) due to 198 | streamlining of 199 | names and the process of name lookup; 200 | \item soundness of type inference, i.e., the run-time 201 | semantics of the language does not depend on the precision of 202 | compile-time type information (which is crucial in a language with 203 | dynamic typing). 204 | \end{itemize} 205 | 206 | As long as a function defined in a namespace is always referenced by 207 | explicitly mentioning the namespace (or, all references to it are statically 208 | bindable), the namespace can be simulated by 209 | an extra parameter taken by the function and a corresponding extra 210 | argument passed to every call of the function. 211 | 212 | Note that the keywords \code{namespace} and \code{use} become redundant, as do 213 | the operator \code{::}. 214 | 215 | In AS3, packages are encoded with namespaces (with package 216 | ``imports'' encoded by namespace ``uses''), and access controls such as 217 | \code{public}, \code{protected}, and \code{private} are also encoded with 218 | namespaces. In AS4, packages and access controls are primitive 219 | concepts, as in Java and C\#. 220 | 221 | See section~\ref{sec:packages-access-controls} for more detail on packages and access control. 222 | 223 | Configuration constants, which dictate conditional compilation, have 224 | thus far been defined in a special namespace \code{CONFIG}. The AS4 syntax 225 | for conditional compilation is explained in section~\ref{sec:conditional-compilation}. 226 | 227 | %To aid porting, we can provide XML libraries that existing code can be 228 | % rewritten to use. 229 | 230 | Without namespaces, E4X cannot stand on its own, so we remove 231 | it. Consequently, we also remove the associated \code{XML}, \code{XMLList}, and 232 | \code{QNames} classes. Removing E4X also means 233 | removing a lot of cruft from the syntax (see section~\ref{redundantOperators}). 234 | 235 | \subsection{Global Object and Package-Level Variables and Functions} 236 | \label{GlobalObject} 237 | There is no notion of a global object in AS4, nor are there any package-level 238 | variables or functions. Instead, there is a {\em main class}, which is anonymous 239 | and is expandable. It is also prepopulated with a few convenience methods such as \code{trace()}. 240 | 241 | See section~\ref{programStructure} about program structure for further 242 | details. 243 | 244 | \subsection{Functions That Implicitly Bind \code{this}} 245 | 246 | In AS3, all functions, including non-method functions (e.g., anonymous 247 | functions, nested functions) implicitly take an additional \code{this} parameter. 248 | 249 | \begin{itemize} 250 | \item Thus, all functions can be used as methods, by attaching them 251 | (explicitly or implicitly) to objects. The 252 | calling convention is such that all calls pass an additional \code{this} 253 | argument, which means that non-method functions are needlessly expensive, 254 | even though such functions are expected to become more common as we 255 | encounter more parallel-friendly code. Also, when there is no explicit \code{this} 256 | argument, currently the global object is 257 | implicitly passed, so without a 258 | global object (see above) we are left with an incomplete feature. 259 | 260 | \begin{verbatim} 261 | function F() { this.x = 0; } 262 | var o:Object = { f: F }; // this in F binds to o 263 | o.f(); 264 | print(o.x); // 0 265 | o.x = 1; 266 | { f: F}.f(); // this in F binds to new object 267 | print(o.x); // 1 268 | \end{verbatim} 269 | 270 | \item Furthermore, all functions can be used as constructors for new 271 | objects, but without prototypes (see below), the utility of this 272 | feature is greatly diminished. 273 | 274 | \begin{verbatim} 275 | function F() { this.x = 0; } 276 | var o:Object = new F(); // this in F binds to o 277 | print(o.x); // 0 278 | \end{verbatim} 279 | 280 | \end{itemize} 281 | 282 | In AS4, the keyword \code{this} may appear only in an instance method, 283 | and may be arbitrarily nested inside other functions. Functions that 284 | are not instance methods do not bind \code{this}, although they may 285 | have \code{this} in scope when they are nested inside instance 286 | methods. 287 | 288 | In AS4, the keyword \code{new} must be followed by a class name 289 | resolved at compile-time. 290 | 291 | Furthermore, functions as constructors do not serve as ``cast'' 292 | operators. The cast operator in AS4 is \code{as}, whose semantics is 293 | modified to throw an error upon cast failure (rather than returning 294 | \code{null}, which is not type-safe since \code{null} is not a valid 295 | value of all types, in particular value types). The \code{as} operator 296 | must be followed by a type, which could be a value type or a class 297 | name. 298 | 299 | Complementing \code{as} is the operator \code{is}, which must also be 300 | followed by a type. AS4 maintains the invariant that \code{v is T} if 301 | and only if \code{v as T === v}, for any compile-time type \code{T} 302 | and run-time value {v}. 303 | 304 | In a later AS4 version, we may provide instance methods of 305 | the \code{Class} class corresponding to \code{new}, \code{is}, and \code{as}, so 306 | that such operations can be applied to types computed at run-time. 307 | 308 | The main benefits of dropping \code{this}-bindable functions is that 309 | closures and the calling convention becomes more lightweight, and 310 | thus, more efficient. 311 | 312 | Functions that implicitly take \code{this} as a parameter can be 313 | simulated by methods in corresponding hidden classes. 314 | 315 | \subsection{The \code{undefined} Value} 316 | 317 | AS3 supports \code{undefined} as the only value of type 318 | \code{void}; it parallels \code{null}, which is a valid value of type 319 | \code{Object}. The type \code{*} includes \code{void} and 320 | \code{Object}; thus both \code{undefined} and \code{null} are valid values of type \code{*}. 321 | 322 | The value \code{undefined} arises in the following cases in AS3: 323 | 324 | \begin{itemize} 325 | 326 | \item Whenever a dynamic property is not found in AS3, \code{undefined} is returned. 327 | 328 | In AS4, missing dynamic properties are denoted by \code{null} instead. 329 | 330 | \begin{verbatim} 331 | var o:* = { }; 332 | print(o.x); // undefined in AS3, null in AS4 333 | \end{verbatim} 334 | 335 | \item In AS3, arrays can have ``holes,'' which are populated by 336 | \code{undefined}. Holes cannot exist in AS4 arrays. 337 | 338 | \item Whenever a function of return type \code{void} is called in AS3, 339 | \code{undefined} is returned as the result. 340 | 341 | In AS4, we throw a compile-time error if it is clear at compile time that a 342 | value of type \code{void} is being expected (because there is no such 343 | value anymore); on the other hand, if it is not clear at compile time 344 | that such a thing may happen, but 345 | it still happens at run time, we throw a run-time error. 346 | 347 | \begin{verbatim} 348 | function f():void { } 349 | var r:* = f(); // OK in AS3, compile-time error in AS4 350 | print(r); // undefined 351 | 352 | var g:* = f; 353 | print(g()); // OK in AS3, run-time error in AS4 354 | 355 | function h():* { return; } // OK in AS3, compile-time error in AS4 356 | \end{verbatim} 357 | 358 | As a corollary of compile-time enforcement, return statements are linked to the type signature 359 | of the enclosing function: if the return type is the dynamic type, 360 | then having a \code{return} statement without an expression is a 361 | compile-time error. 362 | 363 | As an elaboration of run-time enforcement, if a function is called through the 364 | dynamic type, then the compiler makes it explicit in the emitted 365 | bytecode for the (slow) function call whether it expects a result or 366 | not (e.g., emitting \code{call} vs. \code{callvoid}); and as part of the 367 | implementation of the bytecode, the function signature is looked up to 368 | throw a run-time error whenever a value of type \code{void} is 369 | expected. 370 | 371 | \end{itemize} 372 | 373 | The main benefits of dropping \code{undefined} are reduced complexity 374 | in the VM, and a uniform interpretation of \code{*} as a boxed 375 | representation for value or reference types without additional conversion. 376 | 377 | By closing all loopholes for creating uninitialized variables, there is 378 | no reason left to keep \code{undefined} in addition to \code{null}. In AS4, 379 | variables that are not explicitly initialized and are of type \code{Object} or 380 | one of its subtypes are initialized to \code{null}. All variables of 381 | non-\code{Object} types are initialized to a zero-like default value. The 382 | remaining possibility is a variable of type \code{*}. By defining its default 383 | value to be \code{null}, there is no room left for \code{undefined}. It would 384 | just act as a ``second kind of \code{null}'', which is superfluous and just 385 | complicates the language. 386 | 387 | 388 | Note that without the \code{undefined} value, we do not have the unary 389 | \code{void} operator. 390 | 391 | \subsection{Prototypes} 392 | \label{prototypes} 393 | Prototypes provide yet another inheritance mechanism for objects (parallel to the usual inheritance mechanism provided by classes), as 394 | the following example shows: 395 | 396 | \begin{verbatim} 397 | class A { 398 | var x:int = 6; 399 | } 400 | class B extends A {} 401 | 402 | B.prototype.x = 42; 403 | B.prototype.y = 7; 404 | A.prototype.y = 42; 405 | A.prototype.z = 0; 406 | 407 | var o:* = new B(); 408 | print(o.x,o.y,o.z); // 6, 7 409 | \end{verbatim} 410 | 411 | Prototypes have several drawbacks when they coexist with classes. 412 | 413 | \begin{itemize} 414 | \item To support prototypes, every object in the language carries an 415 | extra reference to another object, irrespective of whether it is an 416 | instance of a dynamic class or not. 417 | 418 | \item Furthermore, the fact that some in-built methods of \code{Object} are 419 | dynamic properties accessed via prototype inheritance rather than class inheritance 420 | has several unintuitive implications. 421 | 422 | \begin{verbatim} 423 | class A { 424 | // shadow, not override! (trait properties shadow dynamic properties) 425 | public function toString() { return "some A"; } 426 | } 427 | class B extends A { 428 | // override! (trait properties override trait properties) 429 | override public function toString() { return "some B"; } 430 | } 431 | class C { 432 | // not shadow! (dynamic properties are public) 433 | function toString() { return "some C"; } 434 | } 435 | class D { 436 | // run-time error! (dynamic properties are ignored by compile-time checks) 437 | public var toString = null; 438 | } 439 | print(new A()); // some A 440 | print(new B()); // some B 441 | print(new C(), new C().toString()); // [object C], someC 442 | print(new D()); // error! 443 | \end{verbatim} 444 | 445 | \end{itemize} 446 | 447 | As long as prototype chains are fixed, prototype inheritance can be 448 | simulated by class inheritance. 449 | 450 | By dropping prototypes, objects become smaller, and in-built methods of 451 | Object are declared as trait properties in the class itself. 452 | 453 | Note that the keyword \code{instanceof} is dropped. 454 | 455 | % Early binding of methods on Object implies that names of Object 456 | % instance methods become unusable as dynamic property names. 457 | % { toString: true} 458 | 459 | \subsection{Dynamic Classes} 460 | \label{dynamicClasses} 461 | In AS3, every non-final static class can be extended by a dynamic class, which 462 | features dynamic properties. This approximates JavaScript, but falls short of 463 | modelling its entire generality, because dynamic properties in AS3 do not shadow 464 | static properties nor can they replace them nor can static properties be 465 | modified or removed dynamically. 466 | 467 | In order to make the class system fit into the prototype system, AS3 models all 468 | functions as methods so that they can be assigned as values to properties. This 469 | means that every function has an implicit \code{this} parameter, which 470 | dynamically binds to the receiver object upon method invocation. And in case of 471 | a function invocation it dynamically binds to the global object. 472 | 473 | In AS4 we cannot continue this scheme, because it is inefficient to have an 474 | extra parameter for every function call and because there is no such thing as a 475 | global object any more. 476 | 477 | \subsection{\code{ApplicationDomain}} 478 | 479 | In AS3, global definitions are organized into a hierarchy of application domains 480 | at run time, with complicated lookup and binding rules. This feature is useful 481 | in combination with dynamic loading. 482 | 483 | Initially, both dynamic loading and application domains are absent in AS4. 484 | However, we plan to introduce these capabilities into AS4 later, 485 | after moderate redesign relative to AS3. 486 | 487 | \subsection{The \code{Array} Class} 488 | 489 | We eliminate the AS3 class \code{Array}. The class name is reused for fixed-length arrays (see 490 | section~\ref{fixed-length-arrays} and appendix~\ref{Array}), which only retain a small subset of the functionality of 491 | AS3 arrays. 492 | 493 | \subsection{The \code{Proxy} Class} 494 | 495 | We eliminate the \code{Proxy} class in AS4, mainly because its only 496 | existing uses seem to be in Flex. We will re-design \code{Proxy} in 497 | a later version of AS4. 498 | 499 | 500 | \subsection{The \code{include} Construct} 501 | 502 | The \code{include} feature in AS3 allows fragments of code to be 503 | spliced into larger fragments of code. This feature is 504 | problematic for tooling; furthermore, the AS3 parser has several bugs around 505 | this feature. Thus, we drop it in AS4. 506 | 507 | \subsection{Automatic Semicolon Insertion} 508 | 509 | The optionality of semicolons causes complexity in the language definition and 510 | the lexer/parser. The language specification needs to be extremely pedantic 511 | about where a line break can occur or not to disambiguate what is meant (where 512 | the presence or absence of a required semicolon would immediately disambiguate). 513 | Overall, this feature in AS3 breeds implementation errors as well as, in some 514 | cases, program understanding errors. 515 | 516 | \begin{verbatim} 517 | var x = foo // ; 518 | (y as T).bar(); 519 | \end{verbatim} 520 | Without the semicolon, the above code could be mistaken for: 521 | \begin{verbatim} 522 | var x = foo(y as T).bar(); 523 | \end{verbatim} 524 | 525 | 526 | \subsection{Assignment Expressions} 527 | 528 | In AS4 assignments, e.g., \code{x = e}, \code{x += e}, 529 | \code{o.x = e}, \code{o.x += e}, are statements, not 530 | expressions. This means that they cannot appear inside 531 | conditions, argument lists, and so on. 532 | 533 | This restriction avoids common programming errors. 534 | \begin{verbatim} 535 | if (x = y) { ... } 536 | \end{verbatim} 537 | We are aware that this problem is greatly mitigated by the fact that there are no implicit conversions between values of 538 | type \code{bool} and numeric types. But we also believe that avoiding inline assignments in general fosters program 539 | readability and understanding, especially when programming in the large in teams. 540 | 541 | Last but not least, the above restriction paves the way for named parameter passing in a future version of AS4. 542 | \begin{verbatim} 543 | function foo(x:int,y:String) { ... } 544 | foo(y = "..", x = 5); 545 | \end{verbatim} 546 | 547 | \subsection{Rest Parameters} 548 | 549 | We eliminate rest parameters in AS4. Calling a function with rest 550 | parameters involves hidden costs that are not apparent to the 551 | programmer. In particular, any rest arguments need to be boxed and packed into 552 | an array. We believe that the programmer is better served when the full 553 | cost is explicit at the call site, i.e., the function takes an explicit 554 | optional array parameter instead. 555 | 556 | \subsection{List of Dropped Operators} 557 | \label{redundantOperators} 558 | The following AS3 operators are redundant in AS4, and are therefore dropped. 559 | 560 | \begin{description} 561 | \item [unsigned right shift \code{>>>}] - 562 | cf. overloading of right shift, see section~\ref{sec:operators} 563 | 564 | \item [\code{void}] - 565 | cf. dropped feature: undefined 566 | 567 | \item [\code{instanceof}] - 568 | cf. dropped feature: prototypes; operator \code{is} can be used to determine 569 | whether a value is an instance of a given class 570 | 571 | \item [\code{typeof}] - 572 | to be replaced by a method in a reflection package 573 | 574 | \item [\code{delete}] - 575 | it is no longer possible to remove object properties 576 | 577 | \item [\code{in}] - 578 | the structural composition of objects can no longer be inspected without using the dedicated reflection API (see 579 | appendix~\ref{reflection}) 580 | 581 | \item [type casting operator \code{T(e)}] - 582 | replaced by the operator \code{e as T} 583 | 584 | \item [attribute operator \code{@}] - 585 | repurposed for metadata, cf. dropped feature: E4X 586 | 587 | \item [descendant operator \code{..}] - 588 | cf. dropped feature: E4X 589 | 590 | \item [namespace qualifier operator \code{::}] - 591 | cf. dropped feature: E4X 592 | 593 | \item [the rest parameter indicator \code{...}] - 594 | cf. dropped feature: rest parameters 595 | \end{description} 596 | -------------------------------------------------------------------------------- /as4wp/new.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{New Features} 16 | \label{new} 17 | The following first batch of new features for AS4 provides essentials for: 18 | \begin{itemize} 19 | \item laying a sound foundation for functional programming in an 20 | object-oriented setting, 21 | \item enabling high performance computing. 22 | \end{itemize} 23 | 24 | \subsection{The \code{let} Declaration} 25 | In preparation of greater use of concurrency and larger scale 26 | software engineering in ActionScript, and to help program correctness in 27 | general, we strive to make the declaration of constant values easy and to make 28 | immutability the default wherever an explicit indication regarding mutability 29 | is not given. 30 | 31 | In AS3, variables are customarily declared with the keyword \code{var} and constants 32 | with \code{const}. However, constants are not really guaranteed to be constant, 33 | i.e. it is often possible to assign a value to them several times and they 34 | sometimes can be read before written to. 35 | 36 | In AS4, we replace the \code{const} keyword with \code{let} and we reserve 37 | \code{const} for interesting future uses such as making whole data structures 38 | immutable. We hope that the comparative brevity of \code{let} will encourage 39 | much more frequent usage than \code{var} and we back up the usefulness of 40 | \code{let} with these strong guarantees for every variable declared with it: 41 | \begin{itemize} 42 | \item Within each active scope and extent, it has exactly one immutable value 43 | that can ever be observed. 44 | \item It cannot be read before it is initialized. 45 | \item Every control flow path leads to an initialization or to a 46 | state in which it is guaranteed that its value will never be read. The latter 47 | can for example occur when an exception is thrown between its declaration and 48 | its initialization. 49 | \item If there are multiple initializations, then the values they assign can 50 | differ, but it must be provable at compile time that exactly one will execute 51 | in every possible control flow that remains in scope. 52 | \item The compiler ensures all of the above by throwing errors wherever any of 53 | it does not hold. 54 | \end{itemize} 55 | In short: such constants are truly constant. No value mutation can ever be 56 | programmatically observed. This holds for local variables and for 57 | class instance fields. Even though function parameters are not preceded by 58 | either \code{let} or \code{var}, they are always treated as if they were 59 | declared with \code{let}, i.e. they are truly constant as well. 60 | 61 | Both our commitment to promoting immutability and the choice of the keyword 62 | \code{let} instead of \code{const} are deeply rooted in the design philosophy 63 | that AS4 is a multi-style language, which is both object-oriented and 64 | functional. We are aware that \code{const} would be a more familiar keyword for 65 | most of our existing users and that its name immediately indicates immutability. 66 | However, the relevance of these arguments fades quickly with the number of 67 | lines of AS4 code written or read. Looking further ahead, they are outweighed by 68 | the brevity of \code{let}, which matches \code{var} and provides even 69 | indentation, and by its stronger association with functional programming. 70 | This is consistent with our intention to make AS4 surpass today's mainstream 71 | object-oriented languages (JavaScript, Java, C\#, Objective C, ActionScript 72 | 3) in this important regard: functional programming is no longer a mere appendix to 73 | object-oriented programming, it is going to be the primary style used for 74 | algorithm encoding, because it is usually superior in performance and 75 | correctness. This holds especially in concurrent settings. 76 | 77 | Nevertheless, for well-known reasons, object-oriented code is still 78 | expected to dominate much of programming, as it facilitates programming in the 79 | large. So in the spirit of greater harmony with functional programming, 80 | AS4 provides improved support for both static and instance field immutability. 81 | The above guarantees apply to these as well. Whereas this is straight forward 82 | for static fields, a novel approach is needed for instance fields to prevent 83 | situations like the following: 84 | 85 | \begin{verbatim} 86 | class A { 87 | function f() { 88 | } 89 | 90 | function A() { 91 | // compile error in AS4: 92 | this.f(); // reads x before initialization! 93 | } 94 | } 95 | class B extends A { 96 | let x:int; 97 | 98 | override function f() { 99 | print(this.x); 100 | } 101 | 102 | function B(x) { 103 | super(); // calls f() 104 | this.x = x; 105 | } 106 | } 107 | \end{verbatim} 108 | Here, the presumable ``constant'' \code{x} is read before the program assigns a 109 | value to it. Other program languages typically offer solutions along these 110 | lines: 111 | \begin{itemize} 112 | \item The variable \code{x} is already pre-initialized with a default value 113 | (zero) before any user code runs. This means that two distinct values are observable. 114 | Hardly a constant! Although static or dynamic optimization can often determine 115 | that most code only sees the variable after its final assignment, considerable user 116 | code complications remain. 117 | \item The above program is rejected by the compiler as it recognizes that 118 | \code{x} is not a true constant. (This is the case in AS4, but 119 | see below for why this is problematic and how we solve the problem). 120 | \item An enhanced (flow-sensitive/context-sensitive) type system lets \code{x} 121 | be addressable only downstream from its 122 | initialization statement. In such a system, the above program would still not 123 | type check. 124 | \end{itemize} 125 | In the latter two cases, the user would be forced to write a factory class. Much 126 | boilerplate! The next section presents our solution to this 127 | important problem. 128 | 129 | 130 | \subsection{2-Phase Constructors and Truly Constant Fields} 131 | \label{construct2} 132 | In a constructor, every variable field declared by \code{var} is initialized 133 | with a zero-like default value before any user code in the constructor is 134 | executed. This holds even when an explicit initializer is given, since it could 135 | indirectly read the same variable that is about to be initialized. 136 | Constant fields declared by \code{let} can also have an initializer assignment, 137 | but the compiler ensures that they cannot be read during the execution of this 138 | statement. 139 | 140 | Constant initialization can be deferred to the constructor body. Still, each 141 | such deferred constant must be initialized exactly once in every possible code 142 | path of the constructor. Example: 143 | 144 | \begin{minipage}{\linewidth} 145 | \begin{verbatim} 146 | class A { 147 | var v :int; 148 | let dateStamp :Date = Date.current(); 149 | let x :X; 150 | 151 | function A(x :X) { 152 | this.x = x; 153 | } 154 | } 155 | \end{verbatim} 156 | \end{minipage} 157 | 158 | The variable field $v$ is initialized to zero. Next, the constant field 159 | $dateStamp$ is initialized to the current data. Finally, the constant field $x$ 160 | must be initialized in the constructor or the compiler will post an 161 | error. 162 | 163 | In order to support the common programming practice of publishing of \code{this} 164 | inside the constructor, constructors are split into two phases. In the first, 165 | default phase, \code{this} can only be used to {\b write} properties of the 166 | object being constructed. Any read operations involving \code{this} are 167 | statically rejected, in particular, \code{this} cannot be passed as an argument, 168 | used to call methods (other than the constructor of the superclass), or aliased 169 | with other variables. In the second, optional phase, the use of \code{this} is 170 | unconstrained. The second phase is expressed in the \code{defer} block. 171 | Example: 172 | 173 | \begin{verbatim} 174 | class B extends A { 175 | let y :Y; 176 | 177 | function B(x :X, y :Y, k: Key, d :Map) { 178 | super(x); 179 | this.y = computeSomething(x, y); 180 | defer { 181 | d.add(key, this); 182 | } 183 | } 184 | } 185 | \end{verbatim} 186 | 187 | \begin{verbatim} 188 | class C extends B { 189 | let z :Z; 190 | 191 | function C(x :X, y :Y, k: Key, d :Map, z :Z) { 192 | super(x, y, k, d); 193 | this.z = z; 194 | print(d); 195 | defer { 196 | print(this); 197 | } 198 | } 199 | } 200 | \end{verbatim} 201 | 202 | It is of course possible to extend a class with a constructor that has a \code{defer} 203 | block with a class whose constructor does not have one: 204 | \begin{verbatim} 205 | class D extends C { 206 | function D(x :X, y :Y, k: Key, d :Map, z :Z) { 207 | super(x, y, k, d, z); 208 | } 209 | } 210 | \end{verbatim} 211 | 212 | The \code{defer} keyword creates a closure that captures the current environment 213 | and schedules this closure to run after all initialization has completed. The 214 | \code{defer} blocks in an inheritance chain are run in inheritance order. 215 | 216 | This new language features accomplishes: 217 | \begin{itemize} 218 | \item No part of \code{this} can ever escape from the initialization part of 219 | the constructor. 220 | \item It is thus impossible to observe the value of an uninitialized field. 221 | \item In the \code{defer} block one can immediately use the constructed object 222 | without first leaving the constructor context. 223 | \item For many use cases it is therefore not necessary to write a factory 224 | method or class. 225 | \end{itemize} 226 | 227 | \subsubsection{Constructor Implementation} 228 | It is instructive to inspect in more detail how constructors with \code{defer} 229 | blocks translate to conventional language features. The general form of the 230 | translation scheme, shown below, relies on closures. 231 | However, it is important to note that such closures can always be inlined away, 232 | and an AOT compiler can inline them away at compile time (as illustrated later). 233 | 234 | For illustration purposes we pretend here that AS4 already has inline anonymous 235 | closures. Please be aware that this feature will be introduced in a later 236 | version and its syntax may change by then. In reality the compiler creates code 237 | for this behavior directly, without the intermediate step of source code as 238 | shown here. 239 | 240 | %Cannot use verbatim mode, because it suppresses the apostrophies 241 | \begin{lstlisting} 242 | static function A.(this :A, x :X) :()=>void { 243 | // A's init code: 244 | this.v = 0; 245 | this.dateStamp :Date = Date.current(); 246 | this.x = x; 247 | return function():void { 248 | // A's deferred code 249 | }; 250 | } 251 | 252 | static function A.(this :A, x :X) { 253 | k = A.(this, x); 254 | k(); 255 | } 256 | 257 | static function B.(this :B, x :X, y :Y, k: Key, d :Map) :()=>void { 258 | k = A.(this, x); // call super 259 | this.y = computeSomething(x, y); // B's init code 260 | return function():void { 261 | k(); 262 | d.add(key, this); // B's deferred code 263 | }; 264 | } 265 | 266 | static function B.(this :B, x :X, y :Y) :()=>void { 267 | k = B.(this, x, y); 268 | k(); 269 | } 270 | 271 | static function C.(this :C, x :X, y :Y, k: Key, d :Map, z :Z) 272 | :()=>void { 273 | k = B.(this, x, y, k, d); // call super 274 | 275 | // C's init code: 276 | this.z = z; 277 | print(d); 278 | 279 | return function():void { 280 | k(); 281 | print(this); // C's deferred code 282 | }; 283 | } 284 | 285 | static function C.(this :C, x :X, y :Y, k: Key, d :Map, z :Z) { 286 | k = C.(this, x, y, k, d, z); 287 | k(); 288 | } 289 | \end{lstlisting} 290 | 291 | And an instantiation statements for each of these classes translate to: 292 | 293 | \begin{verbatim} 294 | a = Heap.allocate(VM.instanceSize(A)); 295 | A.(a, x); 296 | 297 | b = Heap.allocate(VM.instanceSize(B)); 298 | B.(b, x, y, k, d); 299 | 300 | c = Heap.allocate(VM.instanceSize(C)); 301 | C.(c, x, y, k, d, z); 302 | \end{verbatim} 303 | 304 | The above implements that in case of \code{c}, these phases execute in this 305 | listed order: 306 | \begin{enumerate} 307 | \item A's init code 308 | \item B's init code 309 | \item C's init code 310 | \item A's deferred code 311 | \item B's deferred code 312 | \item C's deferred code 313 | \end{enumerate} 314 | 315 | Both the AOT compiler and the JIT can optimize the above code with directed, 316 | aggressive inlining so that compared to constructors without \code{defer} blocks 317 | no extra call overhead actually occurs at runtime. To arrive at such deep 318 | inlining, the optimizer needs to be capable of relatively simple escape analysis 319 | and of reverting closure abstraction. 320 | 321 | In particular, the AOT compiler does not need to emit intermediate closures at 322 | all. For example, the constructor for class \code{C} above can be 323 | inlined to the following: 324 | 325 | \begin{minipage}{\linewidth} 326 | \begin{verbatim} 327 | static function C(this :C, x :X, y :Y, k: Key, d :Map, z :Z) :void { 328 | this.x = x; 329 | this.y = computeSomething(x, y); 330 | this.z = z; 331 | print(d); 332 | d.add(key, this); 333 | print(this); 334 | } 335 | \end{verbatim} 336 | \end{minipage} 337 | 338 | \subsubsection{Exceptions in 2-Phase Constructors} 339 | What if an exception occurs in a constructor? If it is thrown in the init block 340 | and it is not caught, then it escapes the entire constructor, leaving the 341 | program with no reference to the object being constructed whatsoever. However, 342 | all other side-effects on the rest of the program that already occurred by means 343 | of the constructor's code remain in effect. 344 | 345 | If the exception is caught, then its handling code is part of the init block. 346 | The compiler must ensure that also in this case all the above rules for 347 | \code{let}-declared fields apply. Each of them must be assigned exactly once 348 | throughout the entire actual code path and cannot be read. Also, \code{this} 349 | must not escape from exception handlers or \code{finally} blocks. 350 | 351 | If an exception occurs in a \code{defer} block and it is not caught in the same 352 | block, then it is propagated all the way out of the constructor. This means 353 | that no \code{defer} block can catch another one's escaping exception. In such 354 | an event, some user-desired invariants may get broken, but at least system 355 | safety remains intact, even if the new object has been leaked, since it is 356 | already fully initialized. 357 | 358 | \subsection{Static Verification of Constructors and Constants} 359 | 360 | This section summarizes static verification around 361 | \code{super} and \code{let}, to support the above new features. 362 | 363 | \subsubsection{\code{super}} 364 | 365 | If a \code{super} call does not appear in constructor, a default 366 | \code{super} call (with no arguments) 367 | is inserted at the beginning of the constructor. 368 | 369 | Otherwise a \code{super} call 370 | must appear in the beginning of the constructor, and there must not be any other \code{super} 371 | call in the constructor. 372 | 373 | \subsubsection{\code{let}} 374 | 375 | The compiler needs to prove that a {\tt let} is not read before it is 376 | written, and that it is written exactly once. 377 | 378 | At runtime, it should be sufficient to disallow writes to a 379 | {\tt let} through 380 | dynamic code, and have no restriction on its reads. 381 | 382 | \paragraph{Local {\tt let}s} 383 | 384 | The compiler ensures that there is one and only one write to a {\tt 385 | let} as follows: 386 | \begin{enumerate} 387 | \item The \nonterminal{FunctionBody} of a function defined in the same 388 | scope as the {\tt let}, or any other scope enclosed by that scope, must not 389 | write to the {\tt let}. 390 | \item In the control-flow graph of the scope, there must not be any 391 | path from the declaration of the {\tt let} to the end of the scope 392 | on which there is zero or multiple \nonterminal{Assignment}s to the {\tt let}. 393 | \end{enumerate} 394 | 395 | The compiler ensures that there is no read to a {\tt 396 | let} on any path in the control-flow graph of the scope between the 397 | declaration of a {\tt let} and the one and only one write to the 398 | {\tt let}, as follows: 399 | \begin{enumerate} 400 | \item No function defined in the same scope as the 401 | {\tt let} that reads the {\tt let} or recursively calls such a 402 | function, is read (or called) on the path. 403 | \item There is no read of the {\tt let} on the path. 404 | \end{enumerate} 405 | 406 | \paragraph{Static {\tt let}s} 407 | 408 | The compiler ensures that there is one and only one write to a {\tt 409 | let} as follows: 410 | \begin{enumerate} 411 | \item The \nonterminal{FunctionBody} of a function defined in the same 412 | scope as the {\tt let}, or any other scope enclosed by that scope, must not 413 | write to the {\tt let}. Furthermore, the {\tt let} must not 414 | written through a static member reference outside the scope. 415 | (Note that writes may still be 416 | possible in dynamically typed code: e.g., 417 | \verb#{dyn:* = A; A.x = ...}#.) 418 | \item In the control-flow graph of the scope, there must not be any 419 | path from the declaration of the {\tt let} to the end of the scope 420 | on which there is zero or multiple \nonterminal{Assignment}s to the {\tt let}. 421 | \end{enumerate} 422 | 423 | The compiler ensures that there is no read to a {\tt 424 | let} on any path in the control-flow graph of the scope between the 425 | declaration of a {\tt let} and the one and only one write to the {\tt let}, as 426 | follows: 427 | \begin{enumerate} 428 | \item There is no read, write, or call of anything defined outside the 429 | class on 430 | the path, including possibly via dynamically typed code. (Everything 431 | defined outside the class is assumed to read the {\tt 432 | let}. We can narrow this assumption in some cases.) 433 | \item No function defined in the same scope as the 434 | {\tt let} that reads the {\tt let} or recursively calls such a 435 | function, is read (or called) on the path. 436 | \item There is no read of the {\tt let} on the path. 437 | \end{enumerate} 438 | 439 | \paragraph{Instance {\tt let}s} 440 | 441 | The compiler ensures that there is one and only one write to a {\tt 442 | let} as follows: 443 | \begin{enumerate} 444 | \item The \nonterminal{FunctionBody} of a non-constructor function defined in the same 445 | scope as the {\tt let}, or any other scope enclosed by that scope, must not 446 | write to the {\tt let}. Furthermore, a 447 | \nonterminal{DeferStatement} in a constructor must not write to the 448 | {\tt let}. Finally, the {\tt let} must not 449 | written through an instance member reference outside the scope. (Note that writes may still be 450 | possible in dynamically typed code: e.g., 451 | \verb#{dyn:* = this; dyn.x = ...}#.) 452 | \item In the control-flow graph of the constructor, there must not be any 453 | path between the super statement and the defer statement 454 | on which there is zero or multiple \nonterminal{Assignment}s to the {\tt let}. 455 | \end{enumerate} 456 | 457 | The compiler ensures that there is no read to a {\tt 458 | let} on any path in the control-flow graph of the constructor between the 459 | super statement and the one and only one write to the 460 | {\tt let}, as follows: 461 | \begin{enumerate} 462 | \item There is no read of {\tt this} (other than an access of an 463 | instance field) and there is no read (or call) of any instance function on 464 | the path. (Every instance function is assumed to read the {\tt 465 | let}. We can narrow this assumption in some cases.) 466 | \item No function defined in the constructor that reads the {\tt let} or recursively calls such a 467 | function, is read (or called) on the path. 468 | \item There is no read of the {\tt let} on the path. 469 | \end{enumerate} 470 | 471 | 472 | 473 | \subsection{Fixed Length Arrays} 474 | \label{fixed-length-arrays} 475 | In AS3, the class \code{Array} stands for a versatile yet poorly performing 476 | general purpose collection type with indexing. Often, AS3 performance can 477 | receive a boost by replacing code using \code{Array} with code using 478 | \code{Vector} instead. 479 | And we intend to hold on to \code{Vector} (renaming it to \code{ArrayList} 480 | notwithstanding). 481 | However, in many cases, there is no need for even the few remaining features of 482 | \code{Vector} either. 483 | Often, the length of an array/vector is known to be fixed. Then further code 484 | optimizations can ensue and we can obtain even better performance. This will 485 | hold in particular in the presence of concurrency. 486 | 487 | Another reason to introduce fixed length arrays is to increase program 488 | correctness, by encoding a relevant invariant in the type system. 489 | 490 | Arrays are not type-compatible with array lists (vectors). Neither type is a 491 | subtype of the other. However, we provide conversion routines between the two 492 | types as described in section~\ref{vector}. 493 | 494 | \subsubsection{Declaration and Initialization} 495 | This example declares and initializes an array of \code{int} values of length 496 | $4$. 497 | \begin{verbatim} 498 | let a :[]int = new [4]int; 499 | \end{verbatim} 500 | The length must not be omitted. Every array must have a definitive length. 501 | 502 | All array elements are automatically initialized to the default value of the 503 | element type. In this example, this is zero. For object types, it is 504 | \code{null}. However, an explicit initializer can be given: 505 | \begin{verbatim} 506 | let a = new []int{computeHeight(), 2, computePrice(weight, count), 4}; 507 | 508 | let streetNames = new []String{"Anza", "Balboa", "Chavez"}; 509 | \end{verbatim} 510 | The element type must be explicit as shown, and the element count must be 511 | omitted. 512 | 513 | In a future release, the type declaration \code{[]int} will be interpreted as 514 | syntactic sugar for \code{Array}. Either notation will then be allowed 515 | interchangeably. However, realizing this immediately would mean precedent 516 | for generalized generics and we would be forced to introduce related features 517 | prematurely. 518 | 519 | \subsubsection{Indexing and Length} 520 | \label{arrayIndexLength} 521 | Array elements can be accessed with familiar indexing syntax: 522 | \begin{verbatim} 523 | value = a[index]; 524 | a[index] = value; 525 | \end{verbatim} 526 | These are the permitted index types: \code{int} and \code{uint}. Each 527 | of them causes the access in question to be translated internally in a slightly different way. 528 | This is disambiguated by the compiler which can regard this as operator 529 | overloading. 530 | 531 | The meaning of an array access remains the same across all index types as long 532 | as it succeeds. The reported or inserted value will be the same and the location 533 | addressed in the array will be the same irrespectively. However, bounds checking 534 | mechanics may differ: in case of an unsigned index, checking against indices less than zero is 535 | naturally omitted. 536 | 537 | In principle, arrays can have upto $2^{32}-1$ elements. However, runtime memory 538 | management may reduce this at will by rejecting allocations that exceed present 539 | capacity or address ranges. Arrays are thought of as having this method 540 | returning instance length: 541 | \begin{verbatim} 542 | public native final function get length() :int; 543 | \end{verbatim} 544 | We may later introduce an additional array type that has instances of greater 545 | lengths in the 64-bit address range. 546 | 547 | \subsubsection{Arrays of Arrays} 548 | Arrays of arrays can be declared by appending additional \code{[]} bracket 549 | pairs. In the following example only the first dimension gets created 550 | and initialized. No elements that represent the additional dimensions are 551 | created at this point. They have to be assigned individually in subsequent 552 | steps. 553 | \begin{verbatim} 554 | let a2 :[][]String = new [4][]String; 555 | a2[0] = new [5]String; 556 | a2[0][3] = "Hello"; 557 | 558 | let t :String = a2[1][1]; // null pointer exception 559 | let s :String = a2[1]; // type error 560 | let b :[]String = a2[1]; // OK 561 | \end{verbatim} 562 | This change in the construction of the array creates all the substructures as 563 | well: 564 | \begin{verbatim} 565 | // 4 arrays of arrays with 5 strings each: 566 | let a2 :[][]String = new [4][5]String; 567 | 568 | a2[0][3] = "Hello"; 569 | let t :String = a2[1][1]; // succeeds 570 | \end{verbatim} 571 | Additional dimensions can be added. This is only limited by resource capacity 572 | and the developers appetite for complexity. 573 | \begin{verbatim} 574 | let a3 :[][][]String = new [4][5][8]String; // OK 575 | let a3 :[][][]String = new [][5][8]String; // compile error 576 | let a3 :[][][]String = new [4][][8]String; // compile error 577 | let a3 :[][][]String = new [5][4][]String; // OK 578 | \end{verbatim} 579 | Note that the brackets are a type prefix. They denote a type of arrays of what 580 | follows them. This is like in the Go language. 581 | 582 | Initializer syntax for arrays of arrays is as follows: 583 | \begin{verbatim} 584 | let a1 = new []int{1, 2, 3, 4, 5, 6}; 585 | let m2 = new [][]int{{1, 2, 3}, {4, 5, 6}}; 586 | 587 | let a3 = new [][][]int{{{{1, f()}, {1, 2}, {1, 2}}, 588 | {{{1, g()}, {1, 2}, {1, 2}}}; 589 | \end{verbatim} 590 | 591 | A tree data structure such as an array of arrays differs from a 592 | multi-dimensional array, which is one flat, coherent aggregate without any graph 593 | structure. We will introduce this feature in a later release and we have shaped 594 | the above so that it is forward compatible with our plans in this regard. The 595 | prospect of adding multi-dimensional arrays to the language is the reason we did 596 | not simply define comma syntax as sugar for accessing arrays of arrays. 597 | 598 | To preserve the direct applicability of JSON syntax in AS4, we have array 599 | literals such as these: 600 | \begin{verbatim} 601 | let numbers = [1, 2, 3, 4, 5]; 602 | let names = ["David", "John", "Peter"]; 603 | \end{verbatim} 604 | They desugar to: 605 | \begin{verbatim} 606 | let numbers :[]* = new []*{1, 2, 3, 4, 5}; 607 | let names :[]* = new []*{"David", "John", "Peter"}; 608 | \end{verbatim} 609 | 610 | \subsubsection{Explanation of Syntax} 611 | 612 | The syntax for array types has \code{[]} as prefix (following a modern 613 | trend: see the language Go) rather than postfix (which is 614 | the traditional choice). 615 | 616 | Consider what happens with postfix syntax in, say, Java. To initialize 617 | a 4-sized array of \code{String}-arrays, and initialize one of those arrays 618 | to a 5-sized \code{String} array, one may write: 619 | 620 | \begin{verbatim} 621 | String[][] a = new String[4][]; a[0] = new String[5]; 622 | \end{verbatim} 623 | 624 | But this scheme cannot be generalized to arbitrary types instead of 625 | String. For example, if one replaced String by String[], one should 626 | have been required to write the following, which surprisingly is a syntax error! 627 | 628 | \begin{verbatim} 629 | var a:String[][][] = new String[][4][]; a[0] = new String[][5]; 630 | \end{verbatim} 631 | 632 | So Java compromises by requiring a 633 | more complicated interpretation of array type syntax. In other words, 634 | array types are not considered to be of the form \code{T[]}, where 635 | \code{T} could be any type including an array type, but instead array 636 | types are of the form \code{T[]...[]}, where \code{T} is a non-array type. 637 | 638 | Unfortunately, the above scheme is brittle. 639 | 640 | As we have larger and larger types in the language (function types and 641 | array types in this version, possibly generics in a future version), 642 | it would make sense to have type macros, which would then be expected 643 | to expand seamlessly (without causing syntax errors as above). And moving forward, we may 644 | actually want sizes in array types, like Go (a performance-oriented 645 | language), which opens up better code optimization 646 | opportunities. Thus, we would like to have \code{String [4][5]} in addition 647 | to \code{String[][]} to describe the type of an array. In such a scenario: 648 | 649 | \begin{verbatim} 650 | type T = String[5]; 651 | ... = new T[4] 652 | \end{verbatim} 653 | 654 | would macro-expand to: 655 | 656 | \begin{verbatim} 657 | ... = new String[5][4]; 658 | \end{verbatim} 659 | 660 | but actually mean: 661 | 662 | \begin{verbatim} 663 | ... = new String[4][5]; 664 | \end{verbatim} 665 | 666 | This order reversal is fairly unintuitive. To solve this problem, 667 | Go has \code{[]} as a prefix rather than suffix type operator. This reads 668 | well enough (think: \code{Array}), lets one write \code{new [4][5] String} to 669 | mean 4-sized array of 5-sized \code{String}-arrays, and lets one have a 670 | simple type language where \code{[] T} indeed means ``array of \code{T}'' for all \code{T}, even array types. 671 | 672 | There is another, deeper reason (which is related to the above 673 | reasons). Postfix array notation feels natural for programmers who have learned 674 | to parse \code{String[4][5]} en bloc, rather than parsing it as 675 | (\code{String[4]})\code{[5]}. But this idea breaks down when we add another postfix 676 | operator to the language. In particular, we may want to introduce a type of the form \code{T!} in a later version of AS4, that denotes the type of non-null references of type \code{T}. How would that look if we had postfix array notation? Suppose we start with: 677 | 678 | \begin{verbatim} 679 | ... = new String[4][]; 680 | \end{verbatim} 681 | 682 | But we want to actually be more specific, and say that we want a 4-sized array of non-null \code{String}-arrays. We would then have to write something like: 683 | 684 | \begin{verbatim} 685 | ... = new (String[])![4] 686 | \end{verbatim} 687 | 688 | This has nothing to do with the fact that we chose \code{!} to be a postfix 689 | operator. If we try to make it a prefix operator, the interaction actually 690 | becomes worse. 691 | 692 | A readability argument may be made against the new syntax, but it 693 | mostly comes from brain-print. Following the reasoning above, it is no surprise that other modern languages are beginning to reverse this convention. It might well be that in some years the prefix array notation will become the norm and people will simply get used to it and argue why it feels "readable". 694 | 695 | We are not the first to note this problem. As mentioned above, Go 696 | already does this. Other proposals have appeared in the 697 | literature. 698 | For example, C++ type declaration syntax has been rewritten to be 699 | saner.\footnote{\url{http://dl.acm.org/citation.cfm?id=240964.240981}} 700 | The authors use \code{[][] int} syntax in their cleanup of C++ 701 | declarations, and their overall goals include readability. 702 | As another example, the C type declaration syntax has been explained and some 703 | fixes suggested.\footnote{\url{http://dl.acm.org/citation.cfm?id=947627}} The author uses "array of \code{int}" syntax, the 704 | English equivalent of \code{[] int}, in his systematic explanation of 705 | C's confusing declaration syntax. 706 | (Careful readers of the second paper will note that the simplified 707 | syntax in the appendix leaves array declarations as they are; the 708 | first paper cites the second and states that the second paper 709 | (chronologically first) didn't go far enough.) 710 | 711 | In summary, there is no getting around the fact that postfix arrays 712 | make sense only because we don't realize that we are parsing the 713 | dimensions "in reverse" by habit, but that breaks down when we have 714 | anything else that needs to interleave seamlessly with this parsing 715 | rule. The problem is not with postfix per se, but with the fact that 716 | we additionally desire the textual ordering of dimensions to be the 717 | same as the textual ordering of access operations. This problem is 718 | guaranteed to surface when we try to add more type operators to the 719 | language, as we will invariably do to expose more and more 720 | optimization opportunities to the programmer. (That is a design theme 721 | that we are going to adhere to moving forward.) 722 | 723 | \subsection{Function types} 724 | One of the larger holes in AS3's type system is that all functions have the same 725 | type, \code{Function}. For almost all uses besides \code{*}-typing, it can be 726 | closed completely in AS4 using the following syntax. 727 | \begin{verbatim} 728 | function foo(i :int, s :String) :double {...} 729 | let f :(int, String) => double = foo; 730 | let d :double = f(1, "Hello"); 731 | \end{verbatim} 732 | The parentheses must always be present, even when the parameter list is empty: 733 | \begin{verbatim} 734 | function bar() :void {...} 735 | let g :() => void = bar; 736 | g(); 737 | \end{verbatim} 738 | % Also note that \code{void}, which indicates that the function does not return 739 | % anything, must be mentioned explicitly and cannot be omitted. 740 | 741 | \subsubsection{Subtyping of function types} 742 | 743 | Recall that if a value of type $T$ flows to a variable of type $S$, 744 | then the compiler checks that $T$ is a subtype of $S$, or $T$ is 745 | implicitly convertible to $S$. 746 | 747 | A function type of the form 748 | $\code{(}T_1\code{,}\dots\code{,}T_n\code{) => } T$ 749 | is considered a subtype of a function type of the form 750 | $\code{(}S_1\code{,}\dots\code{,}S_n\code{) => } S$ whenever 751 | $S_1$ is a subtype of $T_1$, \dots, $S_n$ is a subtype of $T_n$, and 752 | $T$ is a subtype of $S$. This is consistent with the intuition that a 753 | function that takes less precise types and returns a more precise type 754 | can act like a function that takes more precise types and returns a 755 | less precise type. 756 | 757 | As usual, a function type is implicitly convertible to and from 758 | \code{*}. Crucially, though, function types that have \code{*} as 759 | parameter or result types are not implicitly convertible to and from 760 | function types of the same shape that have non-\code{*} types in those 761 | positions: such implicit conversion would require wrapping functions 762 | with boxing/unboxing operations, which is deemed too expensive in time 763 | and space. (We might consider this feature later.) 764 | 765 | \subsubsection{Default Parameters} 766 | 767 | The type of a function with default parameters is a subtype of the function's 768 | full signature, which has all parameters specified as non-default. 769 | 770 | \subsection{Type Inference} 771 | 772 | In AS4, the programmer need not specify types at all declaration 773 | sites: missing types can be inferred. This is important because of 774 | several reasons: 775 | 776 | \begin{itemize} 777 | \item Dynamically typed code is not obligated to be optimized at all by the 778 | compiler and runtime; indeed, dynamically typed code is expected to be 779 | very slow, so the cost of not writing a type in AS4 is 780 | much more than in AS3. 781 | \item As types become more expressive, they also become more verbose (e.g., function 782 | types and array types in AS4), and it becomes 783 | more and more tedious to write down static types to ensure good 784 | performance. 785 | \item With richer numeric types and tighter typechecking around numeric types in AS4, it is 786 | sometimes better to let the compiler figure out the best possible 787 | representation for a location rather than specify it explicitly. 788 | \end{itemize} 789 | 790 | Type inference 791 | infers static types where possible, and may fall back to inferring the 792 | dynamic type (emitting warnings). 793 | 794 | Type inference is limited to the following cases: 795 | 796 | \begin{itemize} 797 | \item Type inference can always infer types of \code{let}s. 798 | 799 | \item Type inference can always infer types of local variables. 800 | 801 | \item Type inference can always infer return types of functions. 802 | 803 | \item The programmer must specify parameter types of functions: type 804 | inference will fall back to the dynamic type for missing parameter types. 805 | 806 | \item The programmer must specify types of any non-\code{let} instance variables and 807 | static variables: type 808 | inference will fall back to the dynamic type for missing types of non-\code{let} 809 | instance variables and static variables. 810 | \end{itemize} 811 | 812 | This design encourages developers to transform more instance and static 813 | \code{var} declarations to \code{let} declarations, and to leave it to the 814 | compiler to figure out best possible representations for local variables and returns. 815 | 816 | Furthermore, this design allows type inference to be implemented by a 817 | simple, standard data flow analysis: the type of 818 | an expression is computed from the types of its parts, and the type 819 | inferred for a location is the union of the types of all expressions 820 | that may flow to that location. 821 | 822 | Note that in separate compilation scenarios, it is recommended 823 | practice to annotate types for all non-private fields and non-private 824 | methods of classes, including types for \code{let}s and returns that could have 825 | been inferred. 826 | 827 | As an illustrative example, type inference allows the omission of all types other 828 | than parameter types in the following code, without degrading performance. 829 | 830 | \begin{verbatim} 831 | function foo(i :int, s :String) // :double 832 | { 833 | let x = 2; // x :int 834 | var r = x; // r :double, since LUB(int,double) is double 835 | r *= 0.5; 836 | return r; 837 | } 838 | 839 | let f = foo; // f :(int, String) => double 840 | var d = f(1, "Hello"); // d :double 841 | \end{verbatim} 842 | 843 | The LUB relation defined earlier for numeric types is generalized to 844 | arbitrary types, as follows. 845 | 846 | For reference types $A$ and $B$, the LUB is the least common ancestor 847 | in the inheritance hierarchy. 848 | 849 | For function types, the LUB is a function type that takes the 850 | intersection of the parameter types and the LUB of the 851 | result type. 852 | 853 | The intersection of two types $T_1$ and $T_2$ is defined as $T$ if $T$ 854 | is one of 855 | $T_1$ and $T_2$, and is a subtype of the other. In particular, if 856 | $T_1$ and $T_2$ are numeric types then their intersection is defined 857 | only when $T_1 = T_2$. If 858 | $T_1$ and $T_2$ are reference types then their intersection is defined 859 | only when $T_1 = T_2$ or one is an ancestor of the other in the 860 | inheritance hierarchy. 861 | 862 | 863 | % \subsection{Property Maps} 864 | % \label{propertyMaps} 865 | % As explained in section~\ref{dynamicClasses} and~\ref{prototypes}, in AS4 we 866 | % no longer support dynamic properties of instances of class \code{object} nor are 867 | % there so-called dynamic classes. However, we want to preserve the ability to 868 | % textually inline JSON data in AS4 programs and we want to facilitate migration 869 | % from AS3 by maintaining the property access syntax that resembles indexing with 870 | % string arguments. Example: 871 | % \begin{verbatim} 872 | % let x = {name : "Player1", age : 18, strength : 98.5} 873 | % x["money"] = 1000; 874 | % if (x["name"] == "Player1") { 875 | % x["age"]++; 876 | % } 877 | % \end{verbatim} 878 | % The first statement contains a {\em property map literal}. The second adds a 879 | % property. The third reads and tests one. Finally, there is one that updates a 880 | % property. 881 | % 882 | % All this is very similar to dynamic object properties in AS3, but there is no 883 | % conflation with access to static object properties (which are accessed by 884 | % ``.''). These two realms are now cleanly segregated. 885 | % 886 | % The above is supported by the base class \code{PropertyMap}, which has these 887 | % methods: 888 | % \begin{verbatim} 889 | % public class PropertyMap { 890 | % public final function get(key :String) :* { ... } 891 | % public final function put(key :String, value :*) { ... } 892 | % public final function delete(key :String) { ... } 893 | % public final function contains(key :String) { ... } 894 | % } 895 | % \end{verbatim} 896 | % The indexing syntax is compiler-supported syntactic sugar for calls 897 | % to the former two methods. Here are the same statements as above in their 898 | % desugared form: 899 | % \begin{verbatim} 900 | % x.put("money", 1000); 901 | % if (x.get("name") == "Player1") { 902 | % x.put("age", x.get("age") + 1); 903 | % } 904 | % \end{verbatim} 905 | % Property maps literals can be used as metadata as shown in 906 | % section~\ref{metadata}. 907 | % 908 | % Note that the familiar AS3 class \code{Dictionary} remains available in 909 | % AS4, mapping \code{Object} keys to \code{*} values. 910 | -------------------------------------------------------------------------------- /as4wp/changes.tex: -------------------------------------------------------------------------------- 1 | % Copyright (c) 2014 Adobe Systems Incorporated. All rights reserved. 2 | 3 | % Licensed under the Apache License, Version 2.0 (the "License"); 4 | % you may not use this file except in compliance with the License. 5 | % You may obtain a copy of the License at 6 | 7 | % http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | % Unless required by applicable law or agreed to in writing, software 10 | % distributed under the License is distributed on an "AS IS" BASIS, 11 | % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | % See the License for the specific language governing permissions and 13 | % limitations under the License. 14 | 15 | \section{Modified Features Relative to ActionScript 3} 16 | \label{changes} 17 | Here we list features of AS3 that are 18 | kept in AS4 in some form, and explain how they have evolved. 19 | 20 | \subsection {Program Structure} 21 | \label{programStructure} 22 | An AS4 program consists of a set of files. Each file must contain an optional package directive, optional import 23 | directives, and then a sequence of class definitions and interface definitions. 24 | 25 | A stand-alone program defines a set of classes and interfaces and one static method to call as entry point. 26 | This method must have no argments and return \code{void}. A library simply omits the mentioning of the entry point. 27 | 28 | Program execution begins with the static initializer of the class that contains the static method entry point. Once this 29 | initializer has concluded, the specified static method is executed. 30 | 31 | % \subsubsection{Script Structure} 32 | % Scripts can refer to identifiers in other scripts by means of forward 33 | % declaration, which is available for both variables and functions. Here is an 34 | % example, ``script A'': 35 | % \begin{verbatim} 36 | % var x :int; // forward declaration 37 | % function bar(n :int) :int; // forward declaration 38 | % 39 | % function foo() :int { 40 | % return bar(x); 41 | % } 42 | % x = 4; 43 | % \end{verbatim} 44 | % And ``script B'' in a different file: 45 | % \begin{verbatim} 46 | % var x :int = 12; 47 | % function bar(n :int) :int { 48 | % return n + 3; 49 | % } 50 | % trace(foo()); 51 | % \end{verbatim} 52 | % If script A is followed by script B then the merged main class would look like 53 | % this if it were decompiled: 54 | % \begin{verbatim} 55 | % public class
{ 56 | % ... // prepopulated definitions 57 | % 58 | % public static function foo() :int { 59 | % return bar(x); 60 | % } 61 | % public static var x :int = 12; 62 | % public static function bar(n :int) :int { 63 | % return n + 3; 64 | % } 65 | % 66 | % static { // A, B: 67 | % x = 4; 68 | % trace(foo()); // 7 69 | % } 70 | % } 71 | % \end{verbatim} 72 | % 73 | % If the script order is reversed, this has direct consequences for program 74 | % execution order: 75 | % \begin{verbatim} 76 | % public class
{ 77 | % ... // prepopulated definitions 78 | % 79 | % public static var x :int = 12; 80 | % public static function bar(n :int) :int { 81 | % return n + 3; 82 | % } 83 | % public static function foo() :int { 84 | % return bar(x); 85 | % } 86 | % 87 | % static { // B, A: 88 | % trace(foo()); // 15 89 | % x = 4; 90 | % } 91 | % } 92 | % \end{verbatim} 93 | % 94 | % As shown, in scripts, variables can be declared and initialized multiple 95 | % times, whereupon the compiler checks that all types match. 96 | % This may lead to multiple assignments to the same variable. A variable 97 | % declaration without an initializer does not cause an extra assignment. However, 98 | % the mere existence of the variable causes it to be initialized with a canonical 99 | % default value before the program begins. 100 | % 101 | % Constant definitions (\code{let}) are not allowed in the outermost scope of scripts. 102 | % 103 | % Functions can be declared an arbitrary amount of times, 104 | % but each function must be defined with a body exactly once, 105 | % and all signatures must match exactly. 106 | % 107 | % Script function definitions must not have default parameters. 108 | 109 | \subsubsection{Conditional Compilation} 110 | \label{sec:conditional-compilation} 111 | 112 | Conditional compilation is dictated by configuration constants that are defined 113 | by the following syntax. 114 | \begin{verbatim} 115 | #debug = true; 116 | 117 | #mac = true; #windows = false; #linux = false; 118 | 119 | #platform_is_unix = mac || linux; 120 | \end{verbatim} 121 | 122 | Any directive may be conditionally compiled by guarding the directive 123 | with a configuration 124 | constant that evaluates to a boolean value: 125 | \begin{verbatim} 126 | #test = debug && platform_is_unix; 127 | 128 | #test 129 | print("testing"); 130 | 131 | #test 132 | class TestEnv { ... } 133 | 134 | #test 135 | function test(env) { ... } 136 | 137 | #test { 138 | let env = new TestEnv(); 139 | test(env); 140 | } 141 | \end{verbatim} 142 | 143 | We thus carry over the expressiveness of the AS3 conditional compilation model, 144 | with a more compact syntax that effectively assumes a unique configuration 145 | namespace, which is entered by \code{\#} and applies throughout one 146 | directly following statement or expression. 147 | 148 | Configuration constants can be only defined with constant value type 149 | \code{bool}.\footnote{Additional value types for configuration syntax may become 150 | available later on.} 151 | 152 | \subsubsection{Static Initialization Code} 153 | All static initialization code needs to be marked \code{static}. This 154 | means that in addition to static variable definitions and static 155 | function definitions, any free-standing static initialization code in classes needs to be 156 | enclosed in blocks that are marked \code{static}, for example: 157 | \begin{verbatim} 158 | class A { 159 | let x:String = "..."; 160 | function f():String { return x; } 161 | static { 162 | print(new A().f()); 163 | } 164 | } 165 | \end{verbatim} 166 | 167 | Regarding their internal syntax, such blocks are treated just 168 | like static function blocks. 169 | 170 | \subsubsection{Block Scoping} 171 | Many of AS4's constructs involve code {\em blocks}, which delineate nested identifier scope visibility ranges with 172 | curly braces. Such blocks are subject to certain rules that govern what entity exactly is symbolically referenced and 173 | thus denoted by each and every stated identifier in any given program. Before we provide an overview of these scoping 174 | rules, let's have a look at the variety of different block constructs in AS4. 175 | 176 | An interface has one block. A function body consists of a block. A substatement, e.g., a branch of an 177 | \code{if} statement, is also considered a block. Furthermore, the programmer can insert new blocks at will in any 178 | grammatical position that permits a statement. This includes nesting blocks inside blocks. 179 | 180 | A class definition contains two textually overlayed, but conceptually distinct blocks: 181 | \begin{description} 182 | \item[the instance block] which may contain non-static variable definitions and non-static function definitions, 183 | \item[the static block] which may contain static function definitions, static variable definitions, and static 184 | statement blocks. 185 | \end{description} 186 | 187 | To assess the identifier scopes for any program, the compiler begins by building a global lexical environment that 188 | consists of classes and interfaces. Thereby the global lexical environment is always in scope. 189 | The compiler then builds lexical environments for the static block and the instance block of every class, and the block 190 | of every interface, by visiting these types in inheritance order. Finally, it builds lexical environments for function 191 | bodies and substatement blocks by visiting them in textual order, realizing the following scoping rules. 192 | \begin{itemize} 193 | \item When visiting the static block of a class, the lexical environment of the 194 | static block of the superclass is in scope (if it exists). 195 | \item When visiting the instance block of a class, the lexical environment of the 196 | instance block of the super class is in scope (if it exists), followed by 197 | the lexical environment of the static block of the current class. 198 | \item When visiting any other block, the lexical environment of the 199 | immediately nesting block is in scope. 200 | \end{itemize} 201 | 202 | When visiting a block, function definitions, variable definitions, and statements are visited in textual order. Thus, 203 | the compiler ``knows'' functions and variables as they are declared. Every definition introduces an entry in the lexical 204 | environment, and every lexical reference must bind to entries that appear in the lexical environment in scope. 205 | In other words, statements, variable initializers, and function bodies will not be able to forward-refer to functions 206 | and variables declared later in the scope.\footnote{We plan to implement forward references (respectively recursive 207 | bindings) for local functions in the next version of AS4. Until then, as a temporary limitation, mutually recursive 208 | local functions can only be expressed when nesting one function inside the other.} Furthermore, if a lexical reference 209 | binds to an entry in an outer lexical environment, then a shadowing definition cannot appear in the lexical environment immediately enclosing that 210 | reference. 211 | Examples: 212 | \pagebreak 213 | 214 | \begin{minipage}{\linewidth} 215 | \begin{verbatim} 216 | { 217 | var v0 = 0; 218 | if (b) { 219 | var v0 = 3; // ok, shadow definition, variable can be redefined 220 | function i() { 221 | var y = v0; // ok, y = 3; 222 | } 223 | } 224 | } 225 | \end{verbatim} 226 | \end{minipage} 227 | 228 | \begin{minipage}{\linewidth} 229 | \begin{verbatim} 230 | { 231 | var v0 = 0; 232 | if (b) { 233 | function i() { 234 | // var y = v0; // error: outer v0 is shadowed below 235 | } 236 | var v0 = 3; 237 | 238 | function m(){ 239 | var y = v0; // ok, y = 3 240 | } 241 | } 242 | } 243 | \end{verbatim} 244 | \end{minipage} 245 | 246 | \begin{minipage}{\linewidth} 247 | \begin{verbatim} 248 | { 249 | function g() { 250 | // f(); // error, f only defined below 251 | } 252 | 253 | let x = g(); 254 | 255 | function f() { 256 | return x; 257 | } 258 | } 259 | \end{verbatim} 260 | \end{minipage} 261 | 262 | \subsubsection{Packages and Access Control} 263 | \label{sec:packages-access-controls} 264 | We assume that an AS4 compiler gains knowledge of package names that 265 | may appear in compilation units (obtained either by looking at package directives that 266 | appear in the compilation units in question, or via compiler 267 | switches). Based on this knowledge and the appearance of import 268 | directives in code, references to class names and interface names 269 | are fully qualified by package names as follows. 270 | 271 | We say that \code{p.C} is open in some code if there is an import 272 | directive that appears textually earlier in some block that nests the code, and 273 | it is of the form \code{import p.C} or 274 | \code{import p.*}. This has the effect of making a lexical reference 275 | \code{C} possibly refer to any 276 | \code{public} class \code{C} in package \code{p} (the reference must 277 | be uniquely 278 | resolved at compile time). 279 | 280 | \begin{minipage}{\linewidth} 281 | \begin{verbatim} 282 | package p { 283 | public class C { } 284 | } 285 | \end{verbatim} 286 | \end{minipage} 287 | 288 | \begin{minipage}{\linewidth} 289 | \begin{verbatim} 290 | package q { 291 | import p.C; 292 | function f() { 293 | return new C(); // desugars to new p.C(); 294 | } 295 | } 296 | \end{verbatim} 297 | \end{minipage} 298 | 299 | We assume that the anonymous package is always open. Any code that is outside a 300 | package directive is implicitly considered to be part of the anonymous package 301 | in AS4 (see section~\ref{programStructure}). 302 | 303 | \begin{minipage}{\linewidth} 304 | \begin{verbatim} 305 | package { // anonymous package, internally named %anon% 306 | public class C { } 307 | } 308 | \end{verbatim} 309 | \end{minipage} 310 | 311 | \begin{minipage}{\linewidth} 312 | \begin{verbatim} 313 | package q { 314 | function f() { 315 | return new C(); // desugars to new %anon%.C(); 316 | } 317 | } 318 | \end{verbatim} 319 | \end{minipage} 320 | 321 | We retain the access control modifier \code{internal} with the same meaning as 322 | in AS3: it specifies that an identifier is visible package-wide. Furthermore, it 323 | remains optional as in AS3, i.e. not naming any modifier implies 324 | \code{internal}. Thus, a class \code{C} that is not specified to be \code{public} is available only 325 | to code in the package in which the class is defined (which could be the anonymous 326 | package, of course). 327 | 328 | Inside classes, access controls have the following meanings: 329 | 330 | \begin{itemize} 331 | 332 | \item A \code{public} member \code{m} of a class can be accessed by any code. 333 | 334 | \item A \code{private} member \code{m} of a class can be accessed only by code in 335 | the class in which the member is defined. 336 | 337 | \item An instance \code{protected} member \code{m} that is defined or inherited 338 | by a class can be accessed by code in that class only on references 339 | whose type is that class or some subclass of it. 340 | 341 | \begin{minipage}{\linewidth} 342 | \begin{verbatim} 343 | class A { 344 | protected function f() { }; 345 | function g(x:B) { 346 | this.f(); // OK, routes to f defined in A or its subclasses 347 | x.f(); // OK, routes to f defined in A or its subclasses 348 | } 349 | } 350 | \end{verbatim} 351 | \end{minipage} 352 | 353 | \begin{minipage}{\linewidth} 354 | \begin{verbatim} 355 | class B extends A { 356 | function h(x:A) { 357 | this.f(); // OK 358 | this.g(this); // OK 359 | //x.f(); // not OK, may route to f defined in unrelated C (see below) 360 | } 361 | } 362 | \end{verbatim} 363 | \end{minipage} 364 | 365 | \begin{minipage}{\linewidth} 366 | \begin{verbatim} 367 | class C extends A { 368 | override protected function f() { ... }; 369 | } 370 | new B().h(new C()); 371 | \end{verbatim} 372 | \end{minipage} 373 | 374 | \item A static \code{protected} member \code{m} that is defined in a class 375 | can be accessed by code in that class and its subclasses. (Recall 376 | that static members defined in a class are not inherited by 377 | subclasses, but are still in scope.) 378 | 379 | \begin{minipage}{\linewidth} 380 | \begin{verbatim} 381 | class A { 382 | static protected function f() { }; 383 | static function g() { 384 | //C.f(); // not OK 385 | f(); // OK, desugars to A.f() 386 | } 387 | } 388 | \end{verbatim} 389 | \end{minipage} 390 | 391 | \begin{minipage}{\linewidth} 392 | \begin{verbatim} 393 | class B extends A { 394 | static function h() { 395 | f(); // OK, desugars to A.f() 396 | //C.f(); // not OK 397 | C.g(); // OK 398 | } 399 | } 400 | \end{verbatim} 401 | \end{minipage} 402 | 403 | \begin{minipage}{\linewidth} 404 | \begin{verbatim} 405 | class C extends A { 406 | static protected function f() { ... }; 407 | static function g() { 408 | A.f(); // OK 409 | f(); // OK, desugars to C.f() 410 | } 411 | } 412 | \end{verbatim} 413 | \end{minipage} 414 | 415 | \item A member \code{m} of a class that is not specified to 416 | be \code{public}, \code{private}, or \code{protected} is effectively 417 | \code{internal}. Any \code{internal} member is available 418 | to any code in the package in which the class is defined. It is unavailable to 419 | every other package. 420 | 421 | \end{itemize} 422 | 423 | \subsubsection{Constant Evaluation} 424 | \label{const-eval} 425 | 426 | During lexical environment building, the compiler visits initializers 427 | of \code{let}s in the order they appear; as these initializers are 428 | visited, if they are \emph{compile-time constant} then their values are inlined. Compile-time constants are numeric, boolean, and 429 | string literals, references to other \code{let}s that are in 430 | scope (as dictated by block scoping) and have already been initialized with compile-time constants, 431 | and ``pure'' unary and binary operations over them (including arithmetic, 432 | bitwise, comparison, and logical operators, and casting and type-checking operators). 433 | 434 | \begin{verbatim} 435 | /* block begins */ 436 | 437 | //let x = y; // y not in scope 438 | let y = 1; 439 | let z = y + 1 as double; 440 | 441 | print(z);; // prints 2.0 442 | 443 | /* block ends */ 444 | \end{verbatim} 445 | 446 | 447 | \subsection{Type Hierarchy} 448 | The type hierarchy in AS4 is almost the same as in AS3, but there is a 449 | significant change at the top: value types are now directly under 450 | \code{*} rather than \code{Object}. Although \code{Object} is the 451 | root of all reference types, it does not include value types. 452 | 453 | We distinguish between the notions of subtyping and 454 | conversion between types. Subtyping never involves changing the underlying 455 | representation, whereas conversion may do so. 456 | 457 | Value types have no interesting subtyping relations among themselves, although 458 | some of them implicitly convert to others. Subtyping between reference types 459 | follows their inheritance relations in the type hierarchy. Finally, both value 460 | types and reference types implicitly convert to and from \code{*}. 461 | 462 | \subsubsection{The \code{*} Type and its Uses} 463 | \label{sec:dynamic} 464 | 465 | When an entity (variable, field, etc.) is typed as \code{*}, then we mostly 466 | follow the traditional dynamic typing principle (as seen in various scripting 467 | languages, including JavaScript and former versions of 468 | ActionScript\textsuperscript{\textregistered}) of making the program continue to 469 | run if at all possible no matter what the results. We call this a {\em 470 | dynamically typed code context} as opposed to a {\em statically typed code 471 | context}. 472 | 473 | At the top of the hierarchy, \code{*} is above both value types 474 | (e.g. int, double) and reference types (\code{Object} and its 475 | subclasses). 476 | 477 | The following methods are defined by class \code{*}: 478 | \begin{verbatim} 479 | /** 480 | * @return whether the receiver and the argument are identical. 481 | * Instances of Object are compared by reference. 482 | * They are identical if they resulted from the same instantiation. 483 | * Value type instances are never identical to Object instances. 484 | * Value type instances are identical to each other 485 | * if they have the same type and the same value. 486 | */ 487 | public native final function identical(other :*) :bool; 488 | 489 | /** 490 | * @return an identity hash value for the receiver 491 | * Every receiver indistinguishable from another by "identical()" 492 | * has the same identity hash value. 493 | * Non-identical receivers may have different identity hash values. 494 | * In fact, these will differ with high probability. 495 | */ 496 | public native final function identityHash() :ulong; 497 | 498 | public native function toString() :String; 499 | \end{verbatim} 500 | These methods are inherited by all classes, for both reference types and value 501 | types, as \code{*} is at the top of the type hierarchy. 502 | 503 | In addition to overriding the above, class \code{Object} defines 504 | these methods\footnote{ This is a temporary arrangement, which may change later, with 505 | the introduction of parametric interfaces.}: 506 | \begin{verbatim} 507 | /** 508 | * @return whether the receiver and the argument are equal 509 | * 510 | * In subclasses, 'equal()' and 'equalityHash()' 511 | * should either both be overriden or neither of them. 512 | */ 513 | public function equal(other :*) :bool { 514 | return this.identical(other); 515 | } 516 | 517 | /** 518 | * @return An equality hash value based on the receiver's value contents 519 | */ 520 | public function equalityHash() :ulong { 521 | return this.identityHash(); 522 | } 523 | \end{verbatim} 524 | The method \code{equal} is invoked by the \code{==} operator when comparing two 525 | instances of \code{Object} (in particular strings). 526 | 527 | \subsubsection{Value Types} 528 | \label{sec:value-types} 529 | 530 | AS4 provides the following builtin value types. 531 | \begin{description} 532 | \item[\code{bool}] - the boolean type, a renaming of the AS3 533 | \code{Boolean} type. The size of heap storage of \code{bool} values 534 | is not specified. 535 | \item[\code{byte}]- new in AS4, 8-bit, unsigned machine integer type without 536 | arithmetic operations. 537 | \item[\code{int}] - the name is retained from AS3, but with 538 | different semantics - it is a 32-bit, two's complement machine 539 | integer type with wraparound on overflow. 540 | \item[\code{uint}] - the name is also retained but the type is 541 | given different semantics - it represents an unsigned, 32-bit 542 | machine integer type with wraparound on overflow. 543 | \item[\code{long}] - new in AS4, 64-bit, signed machine integer types with 544 | wraparound on overflow. 545 | \item[\code{ulong}] - new in AS4, 64-bit, unsigned machine integer types with 546 | wraparound on overflow. 547 | \item[\code{double}] - IEEE 754 double precision floating point 548 | number, replacement for the \code{Number} type, which is absent in 549 | AS4.0. 550 | \item[\code{float}] - IEEE 754 single precision floating point 551 | number. 552 | \end{description} 553 | 554 | All value type names are in short form and lowercase. No other value types are 555 | provided and AS4.0 does not allow user-defined value types (yet). 556 | Implicit conversions between numeric types are allowed, if such conversions do 557 | not result in any loss of precision. As a result, implicit conversions between 558 | signed and unsigned integer types are not allowed, unless it can be statically 559 | determined that no loss of precision will occur. 560 | 561 | Unlike in AS3, but 562 | similarly to Java, there are no implicit conversions from and to 563 | \code{bool} values. This may require more typing, but it increases 564 | readability, making the intention to arrive at a binary distinction explicit. 565 | In particular, this means that the following statements 566 | do not work when \code{x} is of type \code{T} where \code{T} is not \code{bool}. 567 | 568 | \begin{verbatim} 569 | if (x) { ... } // error 570 | var y = x || foo(); // error 571 | \end{verbatim} 572 | 573 | % need more about conversions and coercions 574 | This is the complete list of implicit coercions between value types in AS4: 575 | 576 | \begin{center} 577 | \begin{tabular}{| l | l | l |} 578 | \hline 579 | From & To & Static Precondition \\ 580 | \hline 581 | byte & int, uint, long, ulong, double, float & \\ 582 | \hline 583 | int, uint & long, double & \\ 584 | \hline 585 | int & uint, ulong & $\geq 0$ \\ 586 | \hline 587 | long & ulong & $\geq 0$ \\ 588 | \hline 589 | uint & int & $<2^{31}$\\ 590 | \hline 591 | ulong & long & $< 2^{63}$ \\ 592 | \hline 593 | long & double & $\geq-2^{53}, < 2^{53}$ \\ 594 | \hline 595 | ulong & double & $<2^{53}$ \\ 596 | \hline 597 | int & float & $\geq-2^{24}, < 2^{24}$ \\ 598 | \hline 599 | uint & float & $<2^{24}$ \\ 600 | \hline 601 | float & double & \\ 602 | \hline 603 | double & float & literals only, see section~\ref{numlit} for restrictions 604 | \\ 605 | \hline 606 | \end{tabular} 607 | \end{center} 608 | 609 | In addition, every type implicitly converts to \code{*}, and \code{*} implicitly 610 | converts to every other type. Furthermore, a type that is a 611 | subtype of another type implicitly 612 | converts to that type. 613 | Note that we don't consider \code{void} to be a type any more: it is merely a 614 | syntactic keyword. 615 | 616 | 617 | \subsubsection{Equality and Identity} 618 | AS4 retains the \code{==} and \code{===} operators but slightly 619 | modifies their semantics. The meaning of the identity operator 620 | \code{===} is fixed, defined by the language and not modifiable by 621 | user code. For reference types the \code{===} operator tests if two 622 | references point to the identical object. This is analogous to AS3, 623 | except that \code{String} is a reference type in AS4, and two 624 | references to strings with the same contents will not 625 | necessarily test as identical. 626 | 627 | For value types the identity operator will perform value comparison. Informally, 628 | two values are identical if one can be replaced by the other without any 629 | observable effects. As a result, two numeric values of different types are not 630 | considered identical. Moreover, it is in general likely that an attempt to 631 | compare values of different types is unintentional and the possible source of a 632 | bug. Therefore, a compile error is generated if the two operands of \code{===} 633 | do not have a common super type besides \code{*}, which is the case for any pair 634 | of different value types as well as when attempting to compare a value type to a reference type. For 635 | instance, all of these expressions result in compile errors: 636 | 637 | \begin{verbatim} 638 | 5 === new Object() // error 639 | 3 === 3.0 // error 640 | 641 | let n :uint = 2; 642 | -3 === n // error 643 | \end{verbatim} 644 | 645 | The \code{==} operator does allow its operands to be of different value types as 646 | long as generally permitted implicit coercions as listed in section~\ref{sec:value-types} 647 | reach a common type. For example: 648 | \begin{verbatim} 649 | (1 << 31) as int == (1 < 31) as long; // true 650 | (1 as long) << 63 == (1 as long) << 63 as double; // true 651 | (1 << 31) as int == (1 << 31) as uint; // false 652 | \end{verbatim} 653 | For comparisons where both arguments have reference types, \code{==} is 654 | syntactic sugar for the \code{equal()} method. 655 | 656 | When no implicit coercion according to the rules laid out in section~\ref{sec:value-types} 657 | is available, numeric comparison (\code{==,!=,<,<=,>,>=}) of signed and unsigned 658 | integer types results in a compilation error. 659 | This may be considered draconian, however it does prevent surprising cases 660 | occurring in C, such as the following evaluating to \code{1} (C's \code{true}). 661 | \begin{verbatim} 662 | let n: int = 1 << 31; 663 | n + 1 == n as uint + 1 664 | \end{verbatim} 665 | 666 | The identity comparison operator \code{===} generally translates directly to 667 | method \code{identical()} in class \code{*} (see section~\ref{sec:dynamic}), with one 668 | exception that is necessary according to the above rules: if a value type is 669 | compared to a reference type, a {\em compile time} error occurs. To ensure {\em 670 | equivalent} program behavior under dynamic typing, when one or both of the 671 | operands are typed as \code{*}, and the actual runtime types are incomparable in 672 | the above sense, a {\em run time} error is thrown. Value types and reference 673 | types can only be intermixed when the programmer explicitly demands it. Here, 674 | this can be accomplished by choosing to call \code{identical()} directly instead of using 675 | the \code{operator}. Examples for all these situations: 676 | 677 | \begin{verbatim} 678 | let car :Car = new Car(); 679 | let person :Person = new Person(); 680 | car === person // translates to 'car.identical(person)' => false 681 | 682 | let m :int = 4; 683 | let n :int = 5; 684 | m === n // false 685 | n === car // compile error 686 | 687 | let x :* = n; 688 | let y :* = car; 689 | x === y // runtime error 690 | 691 | x.identical(y) // false 692 | y.identical(x) // false 693 | x.identical(5) // true 694 | \end{verbatim} 695 | 696 | The equality comparison operator \code{==} follows analogous rules. 697 | \begin{verbatim} 698 | let car :Car = new Car(); 699 | let person :Person = new Person(); 700 | car == person // translates to 'car.equal(person)' 701 | 702 | let m :int = 4; 703 | let n :int = 5; 704 | m == n // false 705 | n == car // compile error 706 | 707 | let x :* = n; 708 | let y :* = car; 709 | x == y // runtime error 710 | 711 | x.equal(y) // false 712 | y.equal(x) // false 713 | x.equal(5) // true 714 | \end{verbatim} 715 | 716 | 717 | \subsection{Type Literals} 718 | \label{typeLiterals} 719 | In certain syntactic contexts in AS3, the name of a class denotes a 720 | runtime value that represents it for reflective purposes. AS4 also 721 | support this, but with less syntactic ambiguity, by requiring a leading 722 | operator, a colon, that bridges the gap between the type domain and the value 723 | domain. Examples: 724 | \begin{verbatim} 725 | import type.*; 726 | ... 727 | let myClass :Class = :MyClass; 728 | myClass.createInstance(); 729 | let myParameterTypes = []Type{:int, :bool, :MyClass}; 730 | \end{verbatim} 731 | See the reflection API in appendix~\ref{reflection} for further information 732 | about package \code{type} and its utility classes \code{Class} and \code{Type}. 733 | 734 | 735 | \subsection{Numeric Literals} 736 | \label{numlit} 737 | Numeric literals with a decimal point are of type \code{double}. 738 | \begin{verbatim} 739 | let d1:double = 4.7; 740 | let d2 = 4.7; // also double 741 | \end{verbatim} 742 | To obtain values of type \code{float}, one can use casts or 743 | type annotations. 744 | \begin{verbatim} 745 | let f1 :float = 4.7; 746 | let f2 = 4.7 as float; 747 | \end{verbatim} 748 | 749 | Where a \code{double} program literal occurs, these are all possible 750 | interpretations: 751 | \begin{enumerate} 752 | \item The recipient (variable, parameter, field) is known as a 753 | \code{double}. This type checks trivially. 754 | \item The recipient is known to be of type \code{float}. Then an implicit 755 | conversion occurs. Thus float literals do not need a trailing "f" or any 756 | other marker as in other languages. 757 | \item The recipient is subject to type inference. Then the presence of the 758 | program literal forces the inferred type to be \code{double} (unless it is 759 | contradictory anyway), never \code{float}. 760 | \end{enumerate} 761 | 762 | Why is case $2$ OK even though a loss of precision occurs and as a general 763 | design rule we do not permit implicit conversions where this is the case? We allow an 764 | exception from the rule here, because a loss of precision also occurs in case 765 | $1$! With floating point literals of any kind, there is always a hazard 766 | whether one happens to express a number that can actually be represented by the 767 | resulting bit pattern or not. One may type a number and the actually stored 768 | number differs in some decimal places. From this point of view, case $2$ does 769 | not look worse than case $1$. There would be a problem though, if the 770 | programmer were to implicitly expect a certain precision as expressed in your literal. This is why 771 | case $3$ infers \code{double} from floating point literals, unless overruled by 772 | explicit typing. Thus the programmer only encounters extra loss of precision 773 | when explicitly asking for it. 774 | 775 | Numeric literals in decimal form but without a decimal point are of 776 | type \code{int}, unless the literal value does not fit in an \code{int}, in 777 | which case they are of type \code{long}. 778 | \begin{verbatim} 779 | let i1 :int = 3; 780 | let i2 = 3; 781 | let i3:long = 1000000000000000; 782 | let i4 = 1000000000000000; // inferred type is long 783 | \end{verbatim} 784 | % Numeric literals in hexadecimal form are of type \code{uint} unless 785 | % the literal value does not fit in a \code{uint}, in which case they 786 | % are of type \code{ulong} 787 | % \begin{verbatim} 788 | % let blue :uint = 0x0000FF; 789 | % let green = 0x00FF00; 790 | % let muchJava = 0xCAFECAFECAFECAFE; // inferred type is ulong 791 | % \end{verbatim} 792 | String literals are of type \code{String}. The rules for single and 793 | double quotes are the same as in AS3. 794 | \begin{verbatim} 795 | let s1 = "Hello World!"; 796 | let s2: String = '"Hello!", responded the world'; 797 | let s3: String = "bye"; 798 | \end{verbatim} 799 | 800 | In initialization assignments, type annotations on the variable being defined can be used 801 | to request compile-time conversion. Alternatively, the cast operator 802 | syntax can be used (the cast operator on constants is interpreted by 803 | the compiler as a part of constant propagation, see \ref{const-eval}) 804 | \begin{verbatim} 805 | let i2 :uint = 5; // this is fine 806 | let i1 = 5 as uint; // cast syntax 807 | let l2 :long = 5; 808 | let 1l = 5 as long; 809 | \end{verbatim} 810 | 811 | In expression contexts the cast operator syntax can be used to obtain the 812 | desired type of the constant: 813 | \begin{verbatim} 814 | var hibits = (0xFFFFFFFF as ulong) << 32; 815 | \end{verbatim} 816 | % we don't have 0L, OU etc? <<<< 817 | 818 | \subsection{Arithmetic, Bitwise, and Comparison Operators} 819 | \label{sec:operators} 820 | 821 | Integral types are \code{byte}, \code{int}, \code{uint}, \code{long}, and 822 | \code{ulong}. Numeric types are integral types, 823 | \code{double}, and \code{float}. Value types are numeric types and 824 | \code{bool}. Reference types are \code{Object} and its 825 | subclasses, including function types: thus, reference types 826 | are non-value 827 | types other than \code{*}. 828 | 829 | The \emph{least upper bound} (LUB) of two numeric types $T_1$ and $T_2$ is defined as 830 | a numeric type $T_3$ such that $T_1$ and $T_2$ implicitly convert to $T_3$, 831 | and for any other numeric type $T'_3$ such that $T_1$ and $T_2$ also implicitly 832 | convert to $T'_3$, 833 | we have that $T_3$ implicitly converts to $T'_3$. 834 | 835 | The tables in the following subsections outline all possible typings 836 | for various binary and unary operators. 837 | 838 | \subsubsection{Binary \code{+}} 839 | 840 | \begin{center} 841 | \begin{tabular}{| l | l | l | l |} 842 | \hline 843 | \emph{Operands} & \emph{Result} & \emph{Compile-Time Precondition} \\ 844 | \hline 845 | $T_1$, $T_2$ & $T_3$ & $T_1$ and $T_2$ numeric but not both \code{byte}, LUB of $T_1$ and 846 | $T_2$ is $T_3$ (cast both operands to $T_3$) \\ 847 | \hline 848 | $T_1$, $T_2$ & String & $T_1$ or $T_2$ is \code{String} (cast 849 | both operands to 850 | String) \\ 851 | \hline 852 | $T_1$, $T_2$ & \code{*} & $T_1$ or $T_2$ is \code{*} and the other is \code{*} 853 | or numeric (unbox \code{*} operand(s), box result) \\ 854 | \hline 855 | \end{tabular} 856 | \end{center} 857 | 858 | In particular, we have the following typings: 859 | \begin{verbatim} 860 | //byte + byte // ERROR 861 | byte + int = int 862 | int + int = int 863 | uint + uint = uint 864 | int + uint = long 865 | int + double = double 866 | //long + ulong // ERROR 867 | //double + long // ERROR 868 | int + String = String 869 | String + * = String 870 | int + * = * 871 | \end{verbatim} 872 | 873 | \newcommand{\xor}{\mathbin{\char`\^}} 874 | 875 | \subsubsection{Binary \code{-}, \code{*}, \code{/}, \code{\%}} 876 | 877 | \begin{center} 878 | \begin{tabular}{| l | l | l | l |} 879 | \hline 880 | \emph{Operands} & \emph{Result} & \emph{Compile-Time Precondition} \\ 881 | \hline 882 | $T_1$, $T_2$ & $T_3$ & $T_1$ and $T_2$ numeric but not both \code{byte}, LUB of $T_1$ and $T_2$ is $T_3$ (cast to 883 | $T_3$) 884 | \\ 885 | \hline 886 | $T_1$, $T_2$ & \code{*} & $T_1$ or $T_2$ is \code{*} and the other is \code{*} 887 | or numeric 888 | (unbox \code{*} operands, box result) \\ 889 | \hline 890 | \end{tabular} 891 | \end{center} 892 | 893 | \subsubsection{Binary \code{\&}, 894 | \code{|}, \code{\^{}}} 895 | 896 | \begin{center} 897 | \begin{tabular}{| l | l | l | l |} 898 | \hline 899 | \emph{Operands} & \emph{Result} & \emph{Compile-Time Precondition} \\ 900 | \hline 901 | $T_1$, $T_2$ & $T_3$ & $T_1$ and $T_2$ integral but not both \code{byte}, LUB of $T_1$ and 902 | $T_2$ is $T_3$ (cast both operands to $T_3$) \\ 903 | \hline 904 | $T_1$, $T_2$ & \code{*} & $T_1$ or $T_2$ is \code{*} and the other is \code{*} 905 | or integral 906 | (unbox \code{*} operand(s), box result) \\ 907 | \hline 908 | \end{tabular} 909 | \end{center} 910 | 911 | \subsubsection{Unary \code{-}} 912 | 913 | \begin{center} 914 | \begin{tabular}{| l | l | l |} 915 | \hline 916 | \emph{Operand} & \emph{Result} & \emph{Compile-Time Precondition} \\ 917 | \hline 918 | $T$ & $T$ & $T$ numeric but not \code{byte} \\ 919 | \hline 920 | \code{*} & \code{*} & 921 | (unbox \code{*} operands, box result) \\ 922 | \hline 923 | \end{tabular} 924 | \end{center} 925 | 926 | \subsubsection{Unary \code{\~{}}} 927 | 928 | \begin{center} 929 | \begin{tabular}{| l | l | l |} 930 | \hline 931 | \emph{Operand} & \emph{Result} & \emph{Compile-Time Precondition} \\ 932 | \hline 933 | $T$ & $T$ & $T$ integral but not \code{byte} \\ 934 | \hline 935 | \code{*} & \code{*} & 936 | (unbox \code{*} operands, box result) \\ 937 | \hline 938 | \end{tabular} 939 | \end{center} 940 | 941 | \subsubsection{Binary \code{<<}, \code{>>}} 942 | 943 | \begin{center} 944 | \begin{tabular}{| l | l | l | l |} 945 | \hline 946 | \emph{Left Operand} & \emph{Right Operand} & \emph{Result} & \emph{Compile-Time Precondition} \\ 947 | \hline 948 | $T$ & $S$ & $T$ & $T$ integral but not \code{byte}, $S$ is implicitly convertible to \code{int} \\ 949 | \hline 950 | \code{*} & $S$ & \code{*} & $S$ is implicitly 951 | convertible to \code{int} \\ 952 | \hline 953 | \end{tabular} 954 | \end{center} 955 | 956 | \subsubsection{Binary \code{==}, \code{!=}} 957 | 958 | \begin{center} 959 | \begin{tabular}{| l | l | l | l |} 960 | \hline 961 | \emph{Operands} & \emph{Result} & \emph{Compile-Time Precondition} \\ 962 | \hline 963 | \code{bool}, \code{bool} & \code{bool} \\ 964 | \hline 965 | \code{byte}, \code{byte} & \code{bool} \\ 966 | \hline 967 | $T_1$, $T_2$ & \code{bool} & $T_1$ and $T_2$ numeric but not both \code{byte}, 968 | LUB of $T_1$ and $T_2$ is $T_3$ (cast both operands to 969 | $T_3$) \\ 970 | \hline 971 | $T_1$, $T_2$ & \code{bool} & $T_1$ and $T_2$ reference \\ 972 | \hline 973 | $T_1$, $T_2$ & \code{bool} & $T_1$ or $T_2$ is \code{*} (unbox 974 | \code{*} operand(s)) \\ 975 | \hline 976 | \end{tabular} 977 | \end{center} 978 | 979 | \subsubsection{Binary \code{<}, \code{>}, \code{<=}, \code{>=}} 980 | 981 | \begin{center} 982 | \begin{tabular}{| l | l | l | l |} 983 | \hline 984 | \emph{Operands} & \emph{Result} & \emph{Compile-Time Precondition} \\ 985 | \hline 986 | $T_1$, $T_2$ & bool & $T_1$ and $T_2$ numeric but not both \code{byte}, LUB of $T_1$ and 987 | $T_2$ is $T_3$ (cast both operands to 988 | $T_3$) \\ 989 | \hline 990 | $T_1$, $T_2$ & bool & $T_1$ or $T_2$ is \code{*} and the other is 991 | numeric or \code{*} (unbox \code{*} operand(s)) \\ 992 | \hline 993 | \end{tabular} 994 | \end{center} 995 | 996 | 997 | 998 | 999 | \subsection{Object Literals} 1000 | \label{object-literal} 1001 | 1002 | In addition to the AS3 constructor call syntax for object creation, viz. 1003 | \code{new C} and \code{new C(arg1,...,argn)}, we additionally introduce the syntax 1004 | \code{new C}\verb'{'\code{x1=e1,...,xn=en}\verb'}' and \code{new 1005 | C(arg1,...,argn)}\verb'{'\code{x1=e1,...,xn=en}\verb'}', which effectively 1006 | constitutes object literals. 1007 | 1008 | As in AS3, an object literal with a 1009 | missing argument list (in parentheses) is replaced by a call to the 0-ary 1010 | constructor of the specified class. In addition, the assignment list (in braces) is desugared 1011 | to a sequence of assignments to the corresponding fields of the newly 1012 | created object. Syntactically, the class specified in an object 1013 | literal must not be an array type or a function type. 1014 | 1015 | \subsection{Metadata} 1016 | \label{metadata} 1017 | AS4 supports metadata, but changes the syntax from AS3. Syntactically, metadata 1018 | definitions have the exact same shape of object literals, except that 1019 | \code{@} is used to introduce them. For instance: 1020 | \begin{verbatim} 1021 | @Builtin 1022 | @Native(12.0){cls = "DateClass", instance = "DateObject", gc = "exact", construct = "override"} 1023 | public class Date { 1024 | ... 1025 | } 1026 | \end{verbatim} 1027 | Semantically, only {\em conforming} object literals are 1028 | allowed as metadata, with the leading \code{new} replaced 1029 | by \code{@}. For now, an object literal is conforming if the 1030 | expressions in it are compile-time values of primitive types, strings, or type literals (see 1031 | section~\ref{typeLiterals}) or \code{null}. 1032 | The name following the \code{@} symbol must be a valid class name and the class 1033 | must be a subclass of \code{Object}. 1034 | The classes above are declared as follows. 1035 | \begin{verbatim} 1036 | public class Builtin {} 1037 | 1038 | public class Native { 1039 | var cls :String; 1040 | var instance :String; 1041 | var gc :String; 1042 | var construct :String; 1043 | let version :double; 1044 | function Native(version :double) { this.version = version; } 1045 | } 1046 | \end{verbatim} 1047 | % It is possible to quickly add metadata without declaring a dedicated class: 1048 | % \begin{verbatim} 1049 | % @{timeout : 100, retries : 9} 1050 | % \end{verbatim} 1051 | % This is equivalent to using \code{PropertyMap} as metadata tag, which is 1052 | % consistent with property map literal syntax in general (see 1053 | % section~\ref{propertyMaps}). 1054 | 1055 | \subsection{Strings} 1056 | \label{sec:string} 1057 | 1058 | AS4 strings represent immutable sequences of Unicode code points. The length of 1059 | the sequence is represented as an \code{int}. 1060 | A Unicode ``code point'' is represented as a \code{uint} value in the $[0, 17 * 2^{16}]$ 1061 | range. 1062 | \begin{verbatim} 1063 | public class String extends Object { 1064 | public native final function length() :int; // the number of code points 1065 | public native final function codePointAt(index :int):uint; 1066 | public native final function indexOf(string:String):int; 1067 | override public native final function equal(other :*):bool; 1068 | ... 1069 | } 1070 | \end{verbatim} 1071 | 1072 | The language does not specify which Unicode encoding is used 1073 | internally by its implementation. Indexed access to code points is 1074 | provided via the \code{codePointAt()} method. However, due to the 1075 | internal use of variable-length encodings (e.g. UTF-8), it is not guaranteed nor 1076 | is it likely to have $O(1)$ complexity. 1077 | For fast iteration, it is therefore not advisable to use a loop with a counter index. 1078 | 1079 | \begin{minipage}{\linewidth} 1080 | \begin{verbatim} 1081 | let s :String = ...; // large String 1082 | 1083 | for (int i = 0; i < s.length; i++) { 1084 | let codePoint = codePointAt(i); // SLOW! 1085 | ...codePoint... 1086 | } 1087 | \end{verbatim} 1088 | \end{minipage} 1089 | 1090 | There is no way to iterate quickly over the characters of a string, 1091 | but we intend to add one later. 1092 | Until then, a string can be rapidly converted to an array of code points: 1093 | \begin{verbatim} 1094 | let codePoints :[]uint = s.toCodePointArray(); // quite quick 1095 | 1096 | for (int i = 0; i < codePoints.length; i++) { 1097 | let codePoint = codePoints[i]; // FAST 1098 | ...codePoint... 1099 | } 1100 | \end{verbatim} 1101 | 1102 | Unlike in AS3, identity comparison of \code{String} objects does not 1103 | result in content comparison. For instance, the language does not 1104 | guarantee that \code{'Hello' + (function():String{ return "World";})()} 1105 | is identical to \code{'HelloWorld'}. 1106 | 1107 | The absolute maximum length of strings is $2^{32}-1$ as the return type of 1108 | \code{String.length()} is \code{int}. However, the actual maximum size that can 1109 | be created in a program is limited to whatever the current runtime allows. 1110 | 1111 | \subsection{\code{Vector} becomes \code{ArrayList}} 1112 | \label{vector} 1113 | AS3 has a variable length array type called \code{Vector}, which is 1114 | parametrized by its element type. We provide a very similar construct that is 1115 | now called \code{ArrayList}. However, the type syntax no longer contains a 1116 | ``.''. For example: 1117 | \begin{verbatim} 1118 | var v :Vector. = new Vector.(4,false); // old syntax 1119 | var l :ArrayList = new ArrayList(4); // new syntax 1120 | \end{verbatim} 1121 | 1122 | The option to dynamically fix the length of a vector is preserved, but there is 1123 | no way to change the length again once it is fixed. 1124 | This method in class \code{ArrayList} replaces the field \code{Vector.fixed}. 1125 | \begin{verbatim} 1126 | /** 1127 | * Prohibit length mutation of this array list going forward. 1128 | * @return an array that contains the same elements as the receiver 1129 | * Repeated calls may return the identical array. 1130 | * The implementation may or may not have copy overhead. 1131 | * Aliasing may occur when accessing the resulting array 1132 | * and the original array list as well. 1133 | * 1134 | * This is a temporary measure for our first release. 1135 | * We will follow up with a parametrically typed version later. 1136 | * This later version will also always provide no-copy aliasing. 1137 | */ 1138 | public native function fixLength() :*; 1139 | \end{verbatim} 1140 | 1141 | The constructor no longer has the length fixing boolean argument: 1142 | \begin{verbatim} 1143 | var v :Vector. = new Vector.(4,true); // old syntax 1144 | 1145 | var l :ArrayList = new ArrayList(4); // new syntax 1146 | l.fixLength(); 1147 | \end{verbatim} 1148 | 1149 | There is no object literal syntax for array lists. However, a static method is 1150 | provided for bulk initialization with an array. 1151 | \begin{verbatim} 1152 | /** 1153 | * @return an array list that is populated with the array elements 1154 | * 1155 | * This is a temporary measure for our first limited language release. 1156 | * We will follow up with a parametrically typed alternative constructor later. 1157 | */ 1158 | public static native function create(array :*) :*; 1159 | \end{verbatim} 1160 | 1161 | We would like to provide generic programming against both array lists and arrays 1162 | with a common interface. Unfortunately, the first version of AS4 will not let us 1163 | express this. However, we plan to introduce this capability in a later release 1164 | with generalized parametric types. 1165 | 1166 | \subsection{The \code{override} Method Attribute} 1167 | Use of the \code{override} attribute for methods that do override other methods 1168 | is optional in AS4. We believe that IDEs can indicate the overriding 1169 | relationship and give related warnings as needed. However, we still want to give 1170 | programmers who do not use an IDE the option to declare their intent visibly. 1171 | 1172 | \subsection{For-in enumeration} 1173 | 1174 | The syntax and semantics of \code{for-in} enumeration have been modified to enable more 1175 | aggressive optimizations and facilitate correctness. 1176 | 1177 | \begin{verbatim} 1178 | let v :ArrayList = ...; // length 5 1179 | for (i :int in v) { 1180 | print(v[i]); // executes 5 times 1181 | if (...) v.push("..."); 1182 | } 1183 | \end{verbatim} 1184 | 1185 | In the above code, \code{i} ranges over \code{0..4}, even though the 1186 | length of the array list may change during execution of the loop. 1187 | 1188 | For-in enumeration over arrays obviously works on a fixed key set 1189 | as well, because arrays cannot be grown (or shrunk) in AS4. 1190 | 1191 | Additionally, we drop \code{for-each-in} enumeration. This feature 1192 | will be replaced by ``comprehensions'' in a later version of AS4. 1193 | Meanwhile, common AS3 usecases can be ported by a combination of \code{for-in} 1194 | enumeration and indexing operations. 1195 | 1196 | \pagebreak 1197 | --------------------------------------------------------------------------------