Manuel Serrano
email: manuel.serrano@inria.fr

Vincent Prunet
email: vincent.prunet@inria.fr

A Glimpse of Hopjs

Keywords: D.3.2 [Programming Languages]: Language Classifications-Applicative (functional) languages, Design languages; D.3.4 [Programming Languages]: Processors-run-time environments Web Programming, Functional Programming

Hop.js is a multitier programming environment for JavaScript. It allows a single JavaScript program to describe the client-side and the server-side components of a web application. Its runtime environment ensures consistent executions of the application on the server and on the client.

This paper overviews the Hop.js design. It shows the JavaScript extensions that makes it possible to conceive web applications globally. It presents how Hop.js interacts with the outside world. It also briefly presents the Hop.js implementation. It presents the Hop.js web server implementation, the handling of server-side parallelism, and the JavaScript and HTML compilers.

Introduction

Multitier programming languages unify within a single formalism and a single execution environment the programming of the different tiers of distributed applications. On the web, this programming paradigm unifies the client tier, the server tier, and the database tier when one is used. This homogenization offers several advantages over traditional web programming that relies on different languages and different environments for the two or three tiers: development, maintenance, and evolution are simplified by the use of a single formalism, global static analyses are doable as a single semantics is involved, debugging and other runtime tools are strengthened by the global knowledge of the whole execution [START_REF] Serrano | A Multitier Debugger for Web Applications[END_REF].

The first three multitier platforms for the web, GWT (a.k.a., Google Web Toolkit), Links [START_REF] Cooper | Links: Web Programming Without Tiers[END_REF], and Hop [START_REF] Serrano | HOP, a language for programming the Web 2.0[END_REF], all appeared in 2006. Each relied on a different programming model and a different language. GWT mapped the Java programming model to the web, as it allowed Java/Swing like programs to be compiled and executed on the web; Links was a functional language with experimental features such as storing the whole execution context on the client; Hop was based on the Scheme programming lan-guage [START_REF] Kelsey | The Revised(5) Report on the Algorithmic Language Scheme[END_REF], adapted to the genuine web programming model where HTML is a container for embedded client-side expressions. These three pioneers have opened the way for other multitier languages that have followed (Ocsigen for OCaml [START_REF] Balat | Client-server Web applications with Ocsigen[END_REF][START_REF] Balat | Experience report: ocsigen, a web programming framework[END_REF][START_REF] Vouillon | From bytecode to Javascript: the Js of ocaml compiler[END_REF], Ur/Web [START_REF] Chlipala | An Optimizing Compiler for a Purely Functional Web-Application Language[END_REF], Jsscala [START_REF] Kossakowski | Javascript as an embedded DSL[END_REF][START_REF] Richard-Foy | Efficient high-level abstractions for web programming[END_REF], iTask3 [START_REF] Domoszlai | Tasklets: Client-Side Evaluation for iTask3[END_REF], Cheerp for C++, etc).

In spite of their interesting properties, multitier languages have not yet become that popular on the web. Today, only GWT is widely used in industrial applications but GWT is not a fully multitier language as it requires explicit JavaScript and HTML programming in addition to Java programming. We think that the lack of popularity of the other multitier systems comes mostly from their core based languages rather than from the programming model itself. This is why we are adapting the multitier paradigm to JavaScript, the mainstream web programming language. We have chosen to adapt the programming à la Hop for its proximity with traditional web programming.

JavaScript is the de facto standard on the web. Since the mid 90's it is the language of the client-side programming and more recently it has also become a solution for the server-side programming, popularized by Node.js 1 . Our proposal is to enable multitier programming in JavaScript by extending the language and by implementing a new execution platform that manages the server-side and the client-side of an application. The JavaScript extension is called HopScript, the execution environment is called Hop.js. This environment contains a builtin web server, on-the-fly HopScript and HTML compilers, and many runtime libraries.

HopScript is a super set of JavaScript, i.e., all JavaScript programs are legal HopScript programs. Hop.js is a compliant JavaScript 5 execution environment [START_REF]Standard ECMA-262 -ECMAScript Language Specification[END_REF]. It also integrates some functionalities of ECMAScript 6 (arrow functions, rest arguments, template strings, generators, ...). The Hop.js environment aims at Node.js compatibility. The current version supports about 90% of the Node.js runtime environment. In particular, Hop.js fully supports the Node.js modules, which lets Hop programs reuse existing Node.js modules as is.

The rest of the paper presents HopScript and Hop.js with the following organization: Section 2 presents the architecture of Hop.js web applications; Section 3 presents the server-side programming; Section 4 presents the client-side programming; Section 5 shows how an HopScript program interacts with the outside world; Section 6 shows how multitier programming helps debugging web applications; Section 7 sketches the Hop.js implementation. Section 8 compares it to other web programming languages and environments.

Hop.js Architecture

Hop.js applications are organized as traditional web applications, illustrated in Figure 1. A Hop.js application starts when a Hop.js server is spawned. It first loads its HopScript program, which starts (bootstrap) the server-side execution of the application. This might consists in a mere initialization stage or in a more complex task. The second step of the execution starts when a client, typically a web browser, connects to the server and emits a request (http request). In response, the server computes a response which generally is a HTML page (http response). On reception the client starts executing the HopScript client-side part of the application. In that general framework, the role of HTML is twofold. It is the container of the client-side program and it is the description of the client-side UI.

User interactions may trigger new requests (http request), which in response might produce new HTML fragments that are inserted into the initial page. When these fragments contain clientprograms, they are linked to the existing client-side HopScript program already executing.

Client-side HopScript programs may also trigger server requests (http request), which, in return may insert a new HTML fragment or may replace an existing one. A server-side computation may also emit requests to remote servers (the remote servers on the right hand side of the figure), which are not required to be Hop.js processes.

In the beginning of the paper server-side programs are annotated with $ marks and client-side programs with ~marks (see Figure 1). A HopScript program consists of both programs, combined inside a single source code. The separation between the two ends takes place on the server, by compilation, as illustrated in Figure 2.

Server-Side Computation

The server-side of a HopScript program is a fully capable process running on a server. It can access all the resources of the hosting machine (file system, networking, sensors, ...). For reuse of existing code, HopScript is fully compatible with Node.js. This makes it possible to use most JavaScript npm packages on the Hop.js serverside. In addition, Hop.js also provides libraries of its own (builtin discovery, multimedia, etc.) and multitier operations that are described in this section.

A Hop.js application first starts as a HTTP server, which is builtin in the execution environment. The server delivers HTML documents that contain or point to some code that is installed in the runtime environment of the client and that constitutes the clientside program. During its execution, this client-side program may communicates with its server by invoking services. This is an incarnation of the Ajax (Asynchronous JavaScript and XML) programming paradigm. Services and service invocations are described in this section. Section 5 will show how to use Hop.js services for server-to-server communications and for third-party services interoperability.

HopScript Services

HopScript services are remote JavaScript functions callable via the network, using the HTTP protocol. Syntactically, they are distinguished from regular functions by the use of the service keyword. For instance, the following declares the service readDir, which scans the files of the directory dir, selecting only those whose name matches the regular expression held by the parameter re: var fs = require( "fs" ); service readDir( dir, re ) { let rx = new RegExp( re && ".*" ); return fs.readdirSync( dir ) .filter( s => s.match( rx ) ); } A service is associated with a URL made from its name, http://localhost:8080/hop/readDir in our example. The routing of the HTTP requests and the marshalling/unmarshalling of the arguments are automatic and transparent to the programmer.

As any regular JavaScript function, a service may accept any number of arguments. All the arguments are packed into the special arguments variable. Missing arguments are filled with the undefined value. Services return exactly one result. In the body of a service, this is a JavaScript object containing informations relative to HTTP request that has triggered that service execution: the remote host name, the HTTP header, the HTTP verb, etc.

Service Invocation

Services are JavaScript callable object, but counter-intuitively, calling a service does not evaluate its body. A service call is a purely local operation. It does not involve any network traversal. It merely produces a frame object, which supports the two following operations:

1. URL construction: a frame can be converted into a URL via the toString() method. Using that URL in a HTTP GET, PUT, or POST request triggers an evaluation of the associated service body. As such, all tools and constructs that use URLs (a web browser navigation bar, a src attribute of an HTML image, a wget-like tool, etc.) can provoke service invocations.

2.

Service invocation: a frame can be used by HopScript programs to trigger remote service invocations, via the post(callback) method, or its synchronous declination postSync(). Invoking one of these two methods traverses the network and executes the service on the remote host. The result is sent back to the caller on the other end of the network connection. On that client, the optional callback passed to the post method is invoked asynchronously. The method postSync does not take a callback as parameter. It returns the result of the service invocation. Under the hood, the post and postSync methods are implemented on top of HTTP requests. The frame object merely contains the informations needed to create that request, e.g., the remote host address, a pseudo path associated with the remote service, and the marshalled arguments.

Services may receive any serializable HopScript value, that is, all values but functions, sockets, and workers. As JSON serialization, the HopScript serialization does not follow the prototype chain of JavaScript objects but contrary to JSON, it preserves sharing between values, even amongst parameters.

Services URLs are compatible with the CGI protocol (a.k.a., the Common Gateway Interface) that originally interfaces web servers with executable programs. This protocol describes how program arguments should be packed and encoded in URLs. Hop.js follows this convention for denoting service invocation. Service URLs can be manually forged, knowing the name of the service and the name of arguments. This feature is intensively used to start Hop.js applications or to export HopScript services as regular web services. When the CGI convention is used to invoke a service, all the arguments of the URL are encoded as JavaScript strings and packed together into on fresh JavaScript object that is passed as the single argument of the service.

Service Responses

Invoking a service produces a value. The delivery of that value to the client is handled by the Hop.js server. If needed, the server first compiles the value and then transmits the response, encoded as a sequence of characters, through a HTTP connection. The nature of the response compilation depends on the type of the value produced by the service. For instance, if the response is a HopScript program, it is compiled into a plain JavaScript. If the response is a JavaScript literal, it is compiled into a JavaScript expression that will recreate it on the client. If it is a HTML DOM, it is compiled into plain HTML encoded as a sequence of characters, etc.

For the sake of the example, let us assume a service unameButton that returns a HTML button that when clicked pops up a client window showing the server up time, collected at the service execution time. In that very example, the unameButton result mixes HTML and JavaScript. For the client delivery, the Hop.js server compiles it into:

{"node":hop create encoded element("%3Cbutton%20id%3D%27 G0%27%20onclick%3D%27alert(2.102)%3B%27%3E%0A%20%20%20 %20%20%20%20%20%20%20%20%20%20%20uptime%0A%20%20%20%20 %20%20%3C/button%3E"), "version":1.0}

This sequence of characters is sent, accompanied with a mime type that informs the client on the procedure to be used for decoding it. In that particular example, the decoding will merely consist in evaluating the string, as it denotes an executable JavaScript expression.

In the example. a HTTPResponse is silently and automatically created without the programmer even noticing it. When needed, these objects can also be created by services explicitly. The Hop-Script HTTPResponse class (i.e., JavaScript constructor) is the super class of all possible responses. Its subclasses correspond to the different ways of sending responses to clients. If the service return value is not an HTTPResponse object, it is silently converted using the following rules: For instance, using an explicit HTTPResponseString object, the unameButton service can be rewritten as: // server2.js service unameButton() { var head = { startLine: "HTTP/1.1 200 ok", contentType: "text/hopscript"}; var body = '{"node":hop create encoded element("%3Cbutton%20id%3D%27' +'G0%27%20onclick%3D%27alert(' +process.uptime() +')%3B%27%3E%0A%20%20%20' +'%20%20%20%20%20%20%20%20%20%20%20uptime%0A%20%20%20%20' +'%20%20%3C/button%3E"), "version":1.0}'; return hop.HTTPResponseString( body, head ); } Constructing explicit HTTPResponse objects enable services to specify particular HTTP settings that might be needed, for instance, for communicating with non Hop.js servers or clients. Hop.js provides various classes for building various sort of responses. In the rest of this section, we present the most frequently used ones.

The three main properties of response objects are their HTTP status code, their payload, and their mime type. The status code is required by the HTTP protocol. It informs the client about the success or failure of its request. The mime type, also standard to the HTTP protocol, lets clients interpret the characters they receive. Using different mime types for a same payload yields to different interpretations on the client-side.

The HTTPResponseString class is used to deliver arbitrary sequences of characters. It can be used to send all sort of responses such status or error messages, content of a file, pre-compiled HTML values, etc.

In practice, HTTPResponseString are only used for transmitting values that do not denote HopScript or HTML objects or when a specific mime type is to be specified. For instance, the following example shows a service that returns the content of a file, if that file exists, and a 404 error message otherwise 2 . The class HTTPResponseString is flexible as it can encode all sort of responses but in general it is too low level for the actual needs of the program because it requires an explicitly encoding of the payload as a string of characters. This is burdensome for the programmer and it may impact the performances as it forces the payload to be loaded into the memory and encoded before being transmitted. To solve these two problems (convenience to use and performance) Hop.js supports other classes for responses.

var
Speed: reading a file into memory for delivering it to clients as a string is inefficient on most platforms. Modern operating systems provide more efficient methods that directly write files content to sockets, without even entering the operating system user land. The Hop.js HTTPResponseFile class maps this feature to HopScript. It can be used as follows:

service getFile( path ) { if( fs.lstat( path ) ) { var head = { startLine: "HTTP/1.1 200 ok", contentType: "text/plain" }; return hop.HTTPResponseFile( path, head ); } else { var head = { startLine: "HTTP/1.1 404 no" }; return hop.HTTPResponseString( path, head ); } } HTTPResponseFile enables Hop.js to deliver static files as efficiently as most modern web servers. It is internally used to deliver all system files to clients (default CSS styles, client-side runtime environment, ...).

Convenience: the HTTPResponseHop class is used to deliver JavaScript serialized objects. With such values, the server extracts the payload of the response, serializes it and transmits the encoded characters to the client. The HTTPResponseXML class is used to deliver HTML or more generally XML documents. As HTML values are represented by data structures forming abstract syntax trees (ASTs) on the server (see Section 4), they first need to be compiled into actual textual HTML, before being delivered to a client. The HTTPResponseXML object enables this compilation to be differed to the very moment where the response is send to the client, avoid temporary buffers and string constructions.

Asynchronous Responses

Mainstream web servers are able to answer many requests simultaneously. This can be obtained using two different programming paradigms: concurrency by means of threads or processes and nonblocking asynchronous operations. As JavaScript is a sequential language, it relies on the latter but Hop.js extends it with adhoc constructions that support the former. With Hop.js the two paradigms can be mixed. JavaScript service executions are sequential and rely on non-blocking IO but while a service computes, the server is free to answer other requests (those that do not involve JavaScript executions) or to prepare the data structure of the next service to be executed, or to compile the final result of a previous service invocation for the client delivery (for instance a HTTPResponseXML object).

As presented before, services are synchronous: they produce values that are converted into response objects that are in turn used by the server main loop to respond to client requests. But what happens if a response can only be computed asynchronously? For instance, the previous examples have used the synchronous version of the IO functions (lstat, readFileSync, readdirSync). What about using their asynchronous counterparts? To let services use asynchronous APIs, Hop.js supports another kind of responses: the asynchronous responses. It enables Hop.js services to postpone the delivery of the client responses, without blocking the JavaScript execution. Asynchronous responses rely on ECMAScript 6 promises that are a recent addition to the language and that are used to handle deferred and asynchronous computations. A promise represents an operation that hasn't completed yet, but is expected in the future. When a service returns a promise, the Hop.js runtime system keeps the underlying system socket open for a postponed use. The actual response is only sent when the promise resolves or rejects. Let us illustrate how to use these responses on a concrete example.

The Node.js readFile function of the fs module, implements an asynchronous file read. It accepts as parameters a file name and a callback function to be called when the read completes. Asynchronous functions such as readFile can be used inside services, provided they are wrapped into promises as in the following example:

1 var fs = require( "fs" ); When the resolve argument of the promise executor (line 5) is invoked, the Hop.js runtime system converts the resolved value into a response object as described in Section 3.2 and sends that value to the client. In our example, it is called line 5, when the asynchronous readFile completes.

Using promises as service return values bridges the gap between the asynchronous world of Node.js and the synchronous world of the Hop.js web server loop.

Web Workers

Quoting the Mozilla Developer Network3 , "Web Workers provide a simple means for web content to run scripts in background threads. Once created, a worker can send messages to the spawning task by posting messages to an event handler specified by the creator. However, they work within a global context different from the [global scope]... The Worker interface spawns real OS-level threads, and concurrency can cause interesting effects in your code if you aren't careful. However, in the case of web workers, the carefully controlled communication points with other threads means that it's actually very hard to cause concurrency problems. There's no access to non-thread safe components or the DOM and you have to pass specific data in and out of a thread through serialized objects. So you have to work really hard to cause problems in your code". Conceptually Web workers are more like OS processes than like OS threads as they do not share memory heaps.

Hop.js supports web workers as full-fledged execution entities. They all execute in parallel. They are fully integrated to the execution environment. In particular, services are associated to workers, so several Hop.js services may execute concurrently and simultaneously. During its routing stage, the Hop.js server not only selects the proper service that handles a request. It also selects the worker with which that service is associated with.

Web workers can team up with asynchronous responses to implement some sort of load balancing amongst workers. The resolve function of an asynchronous response can be exchanged with a worker using the postMessage method. For instance, let us consider the following module which implements a time consuming task: In our example, the main worker implements a service that creates promises to delegate the actual response to the background worker (line 18). When the background worker completes, it sends its result using the replier it has received from the main thread (line 6).

Client-Side Computation

Hop.js is meant to run web applications whose server side parts are distributed across multiple Hop.js processes and whose clientside parts are executed by web browsers. As such, generating and manipulating HTML elements is an essential task for many Hop.js applications. HopScript supports HTML as a primordial value as strings or numbers. This is explained in this section.

HTML Values

HopScript treats HTML indifferently on the server-side and on the client-side of the program. HTML fragments are always represented by values that are trees of HTML elements. These values are created and manipulated using a classical HTML representation and a DOM level 2.0 compliant API 4 .

HopScript proposes an extension of the regular JavaScript function call syntax that makes the creation of HTML values identical to plain HTML. Any HopScript functions can be called with the conventional JavaScript function call and also with an equivalent XML-like syntax. This makes the DOM API more comfortable to use. Using the conventional JavaScript syntax, the API might be used as: Using the XML-based syntax, it might be used as:

var table =
var table = <TABLE id="tbl24" class="klass"> <TR><TH>value</TH><TD>99</TD></TR> </TABLE>
The two forms are strictly equivalent but the latter is more familiar to web developers and designers as it does not deviate from plain HTML, it is compatible with interface builders, and it is arguably more readable.

In the example "klass", "tbl24", "99", and "value" are string literals. In real programs, it is frequent that dynamic values need to be to injected into the generated HTML documents. This is the role of the "${" syntactic mark, which follows ECMAScript 6 templates string 5 . It inserts dynamic values into HTML fragments, as in the following example where the constant 99 has been replaced with the variable val: var table = <TABLE id="tbl24" class="klass"> <TR><TH>value</TH><TD>${val}</TD></TR> </TABLE> Tag elements are flattened: they can be HTML elements or nested arrays of HTML elements. This allows HTML constructors and JavaScript higher order operators to be combined together. For instance, this flattening allows an HTML table to be constructed from a JavaScript array using the map iterator as in:

var arr = new Array( ... ); var table = <TABLE id="tbl24" class="klass"> ${arr.map( el => <TR><TD>${el}</TD></TR> )} </TABLE>

The HopScript tag syntax can be used with any function. It can be used in client-side source code as well as server-side source code, with the same semantics. It can also be used to invoke methods as in the following example: With this form, client-side expressions are not opaque strings of characters but an expression of the language whose correctness is ensured by compilation. This improves over traditional HTML string representations.

Values can be inserted inside ~-expressions using the already presented '${' mark. This insertion takes place when the HTML element is created. Example: function mkTable( msg ) { return <TABLE class="example" id="tbl45"> <TR> <TH>value</TH> <TD onclick=~{alert( ${msg} )}>99</TD> </TR> </TABLE>; }

The function mkTable creates HTML tables whose cell is reactive. The variable msg is used at the moment where the table is constructed, to compute the client-side expression that will be executed when, later on, a user will click on the table cell. Note that the function mkTable is multitier as it can be used in server-code and client-code indifferently.

~-Expressions can also be used as HTML elements. In that case, they get automatically compiled into <script> elements. Example:

<html> ~{ var un = ${process.uname()} } <button onclick=~{ alert( un ) }> uname </button> </html>

Full Staging Programming

In the previous section ~{ and ${ were exclusively used to let the server-side program generate the client-side program. This was a simplification as actually the two forms generalize to a full fledged tower of recursive generator/generated elements: a ~{ expression can be nested inside another ~{ expression. That is, a client-side program can generate other client-side programs. In that case, the ~{ and ${ forms denote the generated client-side and generator client-side. The ~{ mark enters a new level of client program; a ${ mark escapes exactly one level. This is illustrated by the following example:

1 service tower() { The tower service creates one button, which when clicked creates one button, which when clicked creates one button, etc. Each nesting level of generated button adds a character to the message of its generator. Clicking again on a button already inserted starts a new thread of button insertions, as illustrated in Figure 3. The ~{ mark line 6 is nested in the client-side expression starting line 3. The ${ mark line 6, escapes one level of client-side expression. Hence the concatenation msg + "+" is executed when the next button is created, before being inserted in the page.

The HopScript multi-staging [START_REF] Taha | Multi-Stage Programming: Its Theory and Applications[END_REF] is not an exotic feature. It is required to unify the server-side programming language and the client-side programming language. It makes HopScript a uniform and global programming language for the servers and the clients. Without this feature, all codes containing a ~{ construct would be tainted as server-side programs and would not be usable on the client-side. This would typically prevent the creation of multitier widgets libraries that can be used indifferently on the server-code and on the client-code.

HTML Assimilation

HTML is part of the full HopScript syntax. HTML texts are then regular HopScript programs. As such, they can then be loaded using the module require library function. For instance: var doc = require('http://slashdot.org/') loads the Slashdot page of the day, parses the HTML document, creates a DOM data structure, and binds it to the variable doc. This document can then be manipulated using the standard DOM api. For instance, creating a table of contents can be done with: function toc( doc ) { return <OL> ${doc.getElementsByTagName( "h2" ).map( LI )} </OL>; } This toc function can be either called from server-side or clientside programs. It shows the benefit of making HTML a builtin construct of the language as it shows how simple it is to re-use and manipulate many third party resources.

Machine to Machine Communications

Machine-to-machine communication is builtin in Hop.js and it has several different facets. The prominent one is the concept of services that enable clients-to-server communications, as presented in Section 3, but also server-to-server communications. This is presented in this section as well as the other constructs that let two machines communicate.

Remote Services

A Hop.js client component, i.e., a Hop.js program running inside a web browser, can only invoke the services of its origin server. A server may invoke the services of other servers. For that, three new Hop.js ingredients are needed. First, the HopScript runtime environment provides the hop.Server class that is used to designate remote machines. Second, services can be imported. It enables a Hop.js program to invoke remote services without disposing of their implementations. Third, when a service is invoked as a method of a server object, the constructed frame designed that remote machine. Example:

1 var mysrv = new hop.Server( "cloud.net", 8080 ); 2 mysrv.translate = service translate(); 3 4 mysrv.translate( "Hello world!", "en|fr" )

5

.post( console.log ); Line 1 is the creation of remote server object. This denotes a remote server, named cloud.net, listening connections on its port 8080. Line 2 imports the service translate. This creates a fake service that can only be used to build service frames (see Section 3.1.1). Line 2 also binds it to the translate property of the server. Line 4 is the service invocation. Service calls follow the syntactic convention of the regular JavaScript function calls, which distinguishes function calls from method calls. When a service is called in function position, the frame it builds designates the local host. When a service is called in the syntactic position of an attribute (here, the attribute translate of the mysrv object), the frame it builds designates the server described by the receiver of the method, here the mysrv server. Using the JavaScript apply, the expression line 4 could be re-written as: 4 translate.apply( mysrv, [ "Hello world!", "en|fr" ] )

5

.post( console.log );

Third Party Web Services

Third party services are an important component of many modern applications. HopScript makes them almost as easy to use as native services. Remote services are created by the webService constructor. Once created, they are only distinguished from Hop-Script services by their arguments passing: third party services can only receive strings. On the other hand, they can deliver results that are automatically unmarshalled by Hop.js, by simply providing an adequate mime type with their responses.

For the sake of the example, here is a HopScript program using a third party natural translation site:

1 var mymemory = 2 new webService( "http://mymemory.net/api/get" ); Line 2 is the creation of the third party service. Line 6 is the call. This service includes in its HTTP response the content-type: text/json header. This tells Hop.js to parse the result accordingly and to create a fresh JavaScript object which is bound to the variable o line 5.

Broadcasting

Broadcasting is the second ingredient of the machine-to-machine communication tool set. It abstracts WebSockets to let Hop.js servers send events to connected clients (either web browsers or Hop.js client processes). Connections originate from the client to the server, so broadcast can be used even in the asymmetric web topology where clients often lie behind a NAT router or firewall and would not accept an incoming connection from a remote server (forbidding the remote server to invoke services running on the client process).

The expression hop.broadcast( event, value ) generates an event named event with payload value. The event is broadcast over the network to all registered clients. Note that private channels may be established by peeking private random event strings only shared by the participants. The argument event is a string, value can be any serializable object, including JavaScript objects, Hop.js services, and XML elements. Clients register to specific broadcast events with the addEventListener method of their builtin server object. Example: function updateGUI( event ) { ... } server.addEventListener( 'refreshScore', updateGUI );

Hop.js processes can also receive broadcast events by creating remote server objects on which they attach listeners: mysrv.addEventListener( 'refreshScore', refresh );

Each time the server designated by the mysrv object will broadcast the event refreshScore, the current Hop.js process will be notified and will react by calling its local listener (here the function refresh).

A server and a client may establish a private broadcast communication channel using broadcast by agreeing on a random key only known by the two parties. This can be implemented in a straightforward manner as:

Debugging HopScript Programs

As already presented in Sections 3 and 4, multitier programming enables a unique and global view of the program being implemented. It also exposes a global view of the execution. The serverside and the client-side executions are under the control of a unique global runtime environment. This gives the opportunity to the runtime environment to report errors in the global execution context [START_REF] Serrano | A Multitier Debugger for Web Applications[END_REF]. This is illustrated by the following program: Line 12 erroneously assumes a method call for the argument arg. When a user clicks on the "click me" button of this web page, the clientAction function is called, which will in turn remotely invoke the serverAction service, that will raise an error. HopScript will report it as follows (slightly embellished for accommodating the paper layout): The stack traces presented by Hop.js contain informations about the two ends of the execution. Not being oblivious of the other side of the execution makes debugging arguably easier.

Implementation

The whole Hop.js system including the various compilers and the web server is implemented in a multi-threaded variant of the Scheme programming language [START_REF] Kelsey | The Revised(5) Report on the Algorithmic Language Scheme[END_REF]. The HopScript code is either compiled to JavaScript for client-side execution, or compiled to Scheme code for server-side execution. This section presents the main components of the Hop.js implementation in order to bring a different perspective to its design.

The Web Server

The builtin web server is a central component of the Hop.js runtime environment as it handles the low level communications between server-side code and client-side code. More precisely, it handles the incoming connections, selects the appropriate HopScript services, invokes the appropriate compiler to generate client responses on the fly, and sends the responses to the clients.

Pipelining is a well known architecture for implementing fast web servers [START_REF] Choi | A Multi-Threaded PIPELINED Web Server Architecture for SMP/SoC Machines[END_REF][START_REF] Welsh | SEDA: An Architecture for Well-Conditioned, Scalable Internet Services[END_REF][START_REF] Yao | Pipeline: A New Architecture of High Performance Servers[END_REF]. It consists of separating in different stages the main treatments applied to incoming HTTP messages. Figure 4 shows the Hop.js pipeline. The first stage named "accept" waits for incoming network connections. It allocates the object representing the client socket. The stage "request" parses the whole HTTP incoming message, including the URL and the HTTP header. It constructs a Hop object representing the request. The stage "response" constructs the response to be sent to the client. For that, it unmarshals service arguments and it routes the request to the proper request handler. The stage "reply" compiles and ships the response obtained from the previous stage to the client. The compilation of the HTML DOM into actual HTML textual representation takes place during that stage, as the client-side program generation. In the case of HTTP/1.1 requests, the same socket can be re-used by the client to make a second request, this improves performance dramatically as accepting a connection and creating a socket object are slow operations [START_REF] Nielsen | Network Performance Effects of HTTP/1.1, CSS1, and PNG[END_REF]. When a socket is reused the pipeline is re-entered in the "request" stage . This architecture supports parallelism as several pipelines can run concurrently. Hop.js runs 20 of them in its default configuration, each being executed inside a dedicated lightweight thread as shown in Figure 5. The benefits of the pipelined architecture have been studied long ago [START_REF] Banga | Measuring the Capacity of a Web Server[END_REF] but it appears to be particularly well suited to Hop.js. In the pipeline, only the "response" stage involves JavaScript executions. All the other stages are handled by the Hop.js runtime environment. Hence, all but the "response" stage can be executed in parallel. In practice, the server can be simultaneously accepting new connections, parsing incoming HTTP headers, unmarshalling services arguments, delivering files, generating HTML, compiling client-side programs, and executing one JavaScript program for preparing a response in parallel. The pipelining architecture of the web server enables Hop.js to take benefit of multi-core architecture, even with JavaScript being intrinsically sequential.

The pipelined architecture enables parallel treatments of HTTP connections, without requiring parallel executions of JavaScript programs. However, as all the dynamic contents Hop.js delivers involve JavaScript executions, a slow or long lasting JavaScript evaluation would downgrade significantly the performance of the whole server. For these particular situations, Hop.js supports a restricted form of parallelism for JavaScript in addition to the asynchronous coding style of Node.js.

Hop.js workers (see Section 3.4) execute in parallel in the "response" stage, as shown in Figure 6. Hop.js services are associated to workers, which enables the HTTP routing to also select the thread that handles a request. After the request object has been created in the "request" stage, the appropriate worker is selected by the Hop.js runtime system for elaborating the response.

Hop.js workers are implemented as OS lightweight threads. The memory isolation is implemented by compilation. Each worker receives a fresh copy of the JavaScript global object, which makes memory sharing impossible. However, for some particular objects, those that are under the exclusive control of the Hop.js runtime system, some sharing is permitted. This is used to exchange promises resolvers and rejecters from one worker to another. As these two functions are not regular JavaScript functions (they are created by the runtime system when a promise object is created) they can benefit from a specific implementation that enables locking and sharing.

Asynchronous responses (see Section 3.3), that can team up with workers, change the normal control flow of the pipeline as shown in Figure 7. When the response stage delivers an asynchronous response, i.e., a JavaScript promise object, the HTTP socket is kept open and the reply stage is delayed until the promise resolves or rejects.

JavaScript Compilation

The HopScript compiler is multi-backend. It produces Scheme code for the servers and JavaScript code for the clients. On the server, the Scheme code is interpreted in debug mode, otherwise compiled to native code. The same AST structure is used for both targets but some compilation stages are skipped when generating JavaScript client code, typically, all the optimizations that aim at improving the speed of the generated Scheme code.

During the parsing of the source program, the XML syntax is desugared to be represented as HTML constructor calls. The ~{ and ${ expressions are represented by two special AST nodes. The AST built for the expression <button onclick=~{clicked( ${msg + "+"} )}> ${msg} </button> has the following shape: Let us illustrate the Hop.js compilation 6 with the tower example of Section 4. First, JavaScript modules are compiled as Scheme functions that take two parameters, the global object (%this), the global scope (%scope). Node.js distinguishes between the global scope in which global variables are defined, and the global object in which builtin values and prototypes are defined. When compiled to Scheme, all functions take an explicit this parameter, which is undefined when the function is not called as a method. The function js-create-service takes as parameters, the function implementing its body, its name, for the URL construction, and the current worker, for the web server routing. The client side expressions are compiled as follows:

"function clicked(msg){ The variable @js-expr1 holds a JavaScript statement as it results of the compilation of a client-side block (see Section 4.3). The variable @js-expr2 holds an expression as it results of the compilation of a node attribute.

When tower is invoked in the response pipeline stage, it calls the @tower function that builds an abstract syntax tree of the HTML document to be responded to the client. That AST is passed to the reply stage that compiles it into actual HTML.

HTML Compilation

The compilation of HTML is mode-dependent. The initial mode is the "node" mode, in which the compilation is mostly a straightforward pretty-print of the HTML AST built in the response stage. The version of HTML to be generated (4.01, 5.0, XHTML, ...) is specified by a compiler flag contained in response objects. When HTML nodes attributes are compiled, the compiler switches to "attribute" mode. In that mode, HTML objects are compiled as references to client-side DOM nodes. This is illustrated by the following compilation example. Let us assume the following expression: The el occurrence (line 4) is compiled as an HTML tag element (line 2 below). The second occurrence (line 5) is inside a TAG attribute. It is then compiled as a reference to a DOM node (line 3 below). Note that Hop.js adds identifiers automatically to all HTML nodes, unless the program provides one already. The HTML compilation normally takes place in the pipeline "reply" stage. The characters produced by the HTML compiler are then directly written to the network socket and there is no overhead associated with storing first the compilation result on a disk or into a string. We have observed that in general, this delivers sufficient performance for most applications. However, in some situations, it might be interesting to implement an application cache for avoiding HTML recompilation. This is left to the charge of the programmer that can deploy the strategy that best fits his needs.

Related Work

Starting in the late 90's we have witnessed an intensive effort in modeling and improving the programming model of web 1.0 applications that was mainly relying on HTML forms and explicit workflows between pages. This has been initially studied by C. Queinnec, that has observed that most form based web applications have to deal with continuations. In his early publication [START_REF] Queinnec | The Influence of Browsers on Evaluators[END_REF] he has shown that a browser is a device that can call continuations multiply and simultaneously. Hence, he has concluded that an operator for capturing and restoring continuations is a natural tool of choice for implementing web pages. This point has been deeply developed and thoroughly studied by the PLT Scheme team in various publications [START_REF] Graunke | Modeling Web Interactions[END_REF][START_REF] Mccarthy | Automatically RESTful Web Applications: Marking Modular Serializable continuations[END_REF]. In the same vain of research, continuations have inspired the design of several languages such as Seaside [START_REF] Ducasse | Seaside: A Flexible Environment for Building Dynamic Web Applications[END_REF] and Links [START_REF] Cooper | Links: Web Programming Without Tiers[END_REF]. Nowadays, the advent of web single page application has made form-based applications less frequent and continuations less popular. Hop.js, which focuses on interactive GUIs and interactive communications between distributed participants does not support them.

Functional reactive programming has many incarnations on the web including Flapjax [START_REF] Meyerovich | Flapjax: A Programming Language for Ajax Applications[END_REF], Elm [START_REF] Czaplicki | Asynchronous Functional Reactive Programming for GUIs[END_REF], Ur/Web [START_REF] Chlipala | An Optimizing Compiler for a Purely Functional Web-Application Language[END_REF][START_REF] Chlipala | Ur/Web: A Simple Model for Programming the Web[END_REF], multi-tier FRP programming in JS-Scala [START_REF] Reynders | Multi-Tier Functional Reactive Programming for the Web[END_REF], React, React.js, StratifiedJS, etc. With these languages, the visible page is implemented as a function over some streams of values that evolve over time or after user interactions. As the streams evolve, the GUI is automatically updated. This alleviates the programmers from explicit, tedious, and error prone DOM manipulations. Hop.js currently support no such things and GUI updates have to be programmed explicitly. We are considering extending HopScript to support lightweight reactive programming. Instead of considering a radical change in the programming model, we are opting for a mere extension, probably provided by the means of a dedicated library made of stream constructors, explicit reactors inserted in the DOM, and a synchronous DSL.

Most web multitier programming languages including Ocsigen [START_REF] Balat | Client-server Web applications with Ocsigen[END_REF][START_REF] Balat | Experience report: ocsigen, a web programming framework[END_REF][START_REF] Vouillon | From bytecode to Javascript: the Js of ocaml compiler[END_REF], Ur/Web, and iTask3 [START_REF] Domoszlai | Tasklets: Client-Side Evaluation for iTask3[END_REF], are also tierless languages [START_REF] Philips | Towards Tierless Web Development without Tierless Languages[END_REF]. They fade out the boundary between the client and the server sides of the programs. Typically a mere annotation distinguished between both ends. This is not the approach followed by Hop.js that, on the contrary, promotes the tiers as first class values of the language. With Hop.js, a client-side program is a server-side value, explicitly computed by a server-side program. In that respect, Hop.js does not deviate from mainstream web server programming that explicitly creates HTML client-side pages containing JavaScript client-side programs.

Hop.js being based on JavaScript it shares many similarities with all the platforms that use this language, especially Node.js. However although Hop.js is compatible with Node.js, i.e., all Node.js programs can be executed in Hop.js 7 , the two systems propose different models for programming web applications. The most notable difference is the Node.js agnostic view of the web. Node.js only provides a low level system API that supports sockets, HTTP, non blocking IOs, some parsing facilities, and an event based loop. Node.js is a runtime environment for programming server-side applications only. Of course, it can be completed by frameworks 8 that raise the level of abstraction but it remains that Node.js is ignorant of the most important aspects that are addressed by Hop.js: the asymmetric client/server architecture of all web applications and HTML.

The support of hardware parallelism also makes Hop.js different from Node.js. As JavaScript is a sequential language, and as the Node.js runtime environment does not support a builtin native loop for handling HTTP requests, the only means Node.js programmers have at their disposal for handling simultaneous requests is asynchronous programming. This model scales naturally well when the traffic load increases as handling more simultaneous requests only involves only allocating more closures that are automatically and efficiently reclaimed when the requests are responded. It has also a down side: it makes program development and maintenance difficult. Hop.js addresses this problem by supporting native parallelism that collaborates with JavaScript sequential codes without being placed under the responsibility of the application programmer.

In PHP and most popular web programming environments, HTML elements are treated as mere strings. With these systems, HTML documents are generated on the server by concatenating strings of characters. This is error prone as it is generally difficult to test the correctness of this dynamically created strings. Using such a textual representation has several drawbacks: the lack of dedicated syntactic constructs makes it inconvenient to program with as the structure of the program diverges from the structure of the elaborated HTML document, it is difficult for a compiler to detect syntax errors, it imposes an asymmetric view to the server-side and to the client-side, it imposes an early decision on the document charset encoding and on the HTML dialect, it exposes the server to SQL-injection attacks [START_REF] Su | The Essence of Command Injection Attacks in Web Applications[END_REF], and many others. Using a textual representation on the server and a DOM based representation on the client is also opposed to the multitier approach which aims at providing an uniform view of the data structures and execution environments.

The HTML tag extension naturally solves these problems as it is based on the genuine HTML syntax. Prior to HopScript, other systems have already opted for the same solution [START_REF] Binsztok | Opa: Up and Running[END_REF][START_REF] Chlipala | Ur/Web: A Simple Model for Programming the Web[END_REF][START_REF] Cooper | Links: Web Programming Without Tiers[END_REF][START_REF]JSX[END_REF]. JSX, aka ReactiveJS seems particularly similar to Hop.js but behind the syntactic resemblance, lies an important difference: JSX does not support anything close to the HopScript Multitier HTML. The consequence is that server-side code and client-side code are asymmetric with JSX, while they are symmetric with HopScript, and then usable on the server-side and the client-side of the application. This is illustrated by the following example. Let us consider an expression creating a reactive HTML div. In JSX it might look like: <div onClick={function() { alert( ... ) }}> {body} </div>

In HopScript the same code should be written: <div onclick=~{ alert( ... ) }> ${body} </div>

The difference seems marginal and purely syntactic (an explicit function in JSX and a ~{ mark in HopScript; an extra $ sign for including computed values as the body of the div). It is not. JSX represents active attribute (onclick, onkeypress, ...) as functions and it does not use staging for elaborating HTML. In JSX, there is only one execution context: the client-side program. This introduces a discrepancy between the HTML code of the server-side program and the XML syntax the client-side program. In standard HTML, the function construction of the active attributes are implicit, while they are explicit in JSX. This implies that the serverside HTML and client-side HTML cannot be used interchangeably, while in HopScript, they are.

At last, as JSX is not a staged language the only way to create function bodies dynamically is to rely on eval, with all the known consequences in term of performance and security. Without eval it is impossible to "inject" server sides values in the active values. This precisely what HopScript ~{ and ${ do.

Modern web browsers also start supporting custom tags declarations 9 . The client-side API they support is shaped by the asynchronous nature of the tag declarations: a web page starts loading, possibly using custom tags, before the JavaScript engine evaluates the custom definitions. Handling this difficulty makes the HTML custom tags elements API more complex than the simple serverside mapping from tags to functions used by HopScript.

StratifiedJS (the Conductance runtime environment) is another approach to multitier programming in JavaScript. It does not rely on a multitier DOM approach as HTML values are constructed using what is now known as template literals. Conductance aims at eliminating all syntactic differences between using local functions or variables and remote ones, as other languages such as Ocsigen, Links, or Ur/Web do. Hop.js relies on different option as the language supports no means for accessing remote variables or functions. Hop.js only supports services that are remotely invoked using dedicated method calls. The Hop.js design decision is motivated by the different nature of calling local and remote functions. The network traversal of the latter makes the speed of the operation uncomparable with the speed of local function calls, and a different semantics as the classical call-by-value semantics has to be abandoned in favor of a call-by-copy semantics.

Conclusion and Perspectives

Hop.js is a new platform for web applications, potentially involving interconnected servers. The server-side execution is compatible with Node.js. Programmers then benefit from numerous existing libraries and applications. Hop.js also introduces distinctive programming features that are expressed in the HopScript programming language, a multitier extension of JavaScript. The Hop.js runtime embeds a multi-backends HopScript compiler.

The HopScript language extends JavaScript to consistently define the server and client part of a web application. HopScript supports syntactic forms that help creating HTML elements. It supports services that enable function calls over HTTP. Being higher level than traditional Ajax programming, Hop.js services avoid the burden and pitfalls of URL management and explicit data marshalling. They combine the benefits of a high level RPC mechanism and low level HTTP compatibility.

Hop.js supports server-side and client-side parallelism. On the server, it first relies on its built-in pipelining architecture that automatically decodes HTTP requests in parallel. It also relies on server-side web workers that programs may explicitly launch to perform background tasks (functions and services). Each worker runs its own system thread. The service invocation and execution API fully integrates with the JavaScript execution flow, allowing synchronous and asynchronous operations on both client and server processes. The asynchronous response API can be combined with the worker API, allowing processing and asynchronous service responses to be delegated between workers. On the browser clientside parallelism relies on standard web workers.

Although Hop.js can be used to develop traditional web servers, it is particularly adapted to the development of web applications embedded into devices, where the server and client part of the application are intimately interoperating with each other. The programing model of Hop.js fosters the joint specification of server and client code, and allows the rapid development of web user interfaces, on the client, controlling the execution of the distributed application. By defining a single data model, providing functions that can run indifferently on both sides, and almost forgetting about client-server protocols, Hop.js seems well suited for agile development of web applications for this class of applications.

As an example, Hop.js has already been successfully used as the core framework to develop embedded and cloud applications for connected robots and IoT devices. In the context of a European industrial collaborative project, it has been used by various categories of programmers (mostly undergraduate internships, robotic experts, and professional engineers familiar with web development techniques) to build complex distributed applications, where various sort of digital equipments (computers, robots, small devices) communicate with each other, discover themselves, and collaborate. In all cases we have observed an easy adoption from everyone. The tons of JavaScript resources and examples available on the web helped internship students to rapidly become productive. Robotic experts were instantly able to start implementing Hop.js applications. Web experts seemed to feel at home with Hop.js as it let them build working applications with Hop.js core features and then extend them with existing JavaScript third party modules, typically npm modules.

In the future, we foresee different axes of research for Hop.js. First, there is room for performance improvements of the JavaScript compilation. We are willing to explore situations where JIT compilation is not necessarily adapted, for instance, when the execution environment only offers a very limited memory capacity. Another research direction we will focus on is orchestration and synchronous/asynchronous programming. Programming a web application involves a lot of events handling. Until recently, this was mostly programmed with callbacks. Recent proposals combine JavaScript programming and dataflow programming. They constitute an interesting alternative to callback programming but we think that there is still room for alternative proposals that not only simplify event handling but that also integrate harmoniously with traditional JavaScript programming techniques.

Figure 1 .

 1 Figure 1. Anatomy of a Hop.js web application.

2 .

 2 Separation between client-side and server-side code by compilation.

2 3 6 if

 26 service getFile( path ) { 4 return new Promise( function( resolve, reject ) { 5 fs.readFile( path, function( err, d ) {

1 3 4

 3 // longlasting.js (worker thread) 2 function longTask( arg ) { ... } onmessage = function( e ) { 5 var reply = e.data.resolve; 6 reply( longTask( e.data.val ) ); 7 } Slave workers can be spawned to execute these tasks in background and to respond when done: 8 // workers pool 9 var workers = [ 0, 1, 2, 3 ].map( function() { 10 return new Worker( "./longlasting.js" ); 11 } ); 12 var windex = -1; 13 14 // main worker 15 service longLasting( arg ) { 16 return Promise( function( resolve, reject ) { 17 if( ++windex > workers.length ) windex = 0; 18 workers[ windex ] 19 .postMessage( { resolve: resolve, val: arg } ); 20 } ); 21 }

  <TD onclick='alert( event.button )'>99</TD> HopScript allows listeners, and more generally, any client-side expression, to be added to HTML elements wherever they are created. These client-side expressions are introduced by a new syntactic form: the ~-expressions, which evaluate to values that can be serialized and sent over the network to clients. ~-Expressions can be used on the two tiers of the application. Example: <TD onclick=~{alert( event.button )}>99</TD>

Figure 3 .

 3 Figure 3. The Chromium browser executing the tower HopScript function.

3 4 6 .

 36 function translateText( text, lang = "en|fr" ) { 5 var o = mymemory( { q: text, langpair: lang } )

File

  "bug1.js", line 12, character 3: | arg.call( 3 ); | TypeError: call1: not a function "undefined" 1. serverAction, bug1.js:11 Service trace: 1. ~serverAction.post(...) 2. ~clientAction, /hop/svc:3 3. ~button#G0.onclick, bug1.js:5 4. $<html>, bug1.js:2 5. $svc, bug1.js:

Figure 4 .

 4 Figure 4. Internal pipeline of the Hop web server.

Figure 5 .

 5 Figure 5. The parallel pipelines of the Hop web server.

Figure 6 .

 6 Figure 6. The JavaScript workers of the reply stage.

Figure 7 .

 7 Figure 7. Internal pipeline of the Hop web server with asynchronous responses.

1 2 ( 8 ( 22 (define tower 23 ( 12 (instantiate::JsTilde 13 (

 2822231213 (define (module %this %scope) define @js-expr1 ...) define @js-expr2 ...)10(define (@tower this) ...) js-create-service %this 24 (js-make-function %this @tower 0)25 "tower" 26 (js-current-worker))))The function @tower implements the service. It calls the HTML global function with two values: a client-side expression (line 12) and an HTML button (line 14). 10 (define (@tower this) 11 (js-call %this (js-get %scope 'HTML) %js-expression @js-expr1)) 14 (js-call %this (js-get %scope 'BUTTON) 15 (with-access::JsGlobalObject %this ( proto ) 16 (instantiate::JsObject

21 "

 21 click me")))

1 <html> 2 4 .

 124 <div id="g4503"></div> 3 <input onclick="document.getElementById('g4503') innerHTML=this.value"/> 5 </html>

  // The module fib.js exports the tag FIG var f = require( "./fig.js" );HTML elements are active when they hold listeners, which are JavaScript client-side functions triggered after users interactions with the HTML graphical interface. In HTML, listeners are introduced as JavaScript fragments, which are attributes values. For instance, making a table cell active can be done with:

	function htmlPage( photo, legend ) {
	return <HTML>
	<f.FIG><IMG src=${photo}/>${legend}</f.FIG>
	</HTML>
	}
	4.2 Multitier HTML

https://nodejs.org/

For simplicity, it is assumed that no race condition with potential file removal can happen in this example.

https://developer.mozilla.org

http://www.w3.org/DOM

ECMA6Script template strings are defined at: http://www.ecma-international.org/ecma-262/6.0/#12-2-9.

The compilation results presented here a manually modified to fit the constraints of the paper.2 (define @js-expr1

Packages that depend on native libraries need special attention.

For instance the Express framework http://expressjs.com/.

See https://w3c.github.io/webcomponents/spec/custom/

Acknowledgments

This work has been supported by the European FP7 RAPP project (FP7-ICT-2013-10, 610947) and the French FUI UCF 8980 project. Special thanks are due to Christian Queinnec for his early comments on this paper and to the ICFP program committee members that have helped improving the paper.


Jing An
email: anjing@tobacco.gov.cnyrqits@163.com

Yanru Qi

Yun Liu

Comparative Studies Between the Regional Economic Growth levels Based on the Three-Stage Weight Dynamic Comprehensive Evaluation

Keywords: Twice stage difference features, Relative balance coefficient, Three times weight. Dynamic comprehensive evaluation. Regional economic growth

This paper proposes a dynamic comprehensive evaluation method based on three times weight. Firstly, this paper determines the index weight based on the twice stage difference driving features. Then it introduces the relative balance coefficient to calculate the comprehensive evaluation value. This method has the following characteristics: 1) The comprehensive evaluation result is totally based on the information provided by the evaluating indicator system, without the influence from subjective factors; 2) The results have direct comparability among different evaluation systems at each time; 3) Motivation or punishment are the characteristics of this method. This approach has been applied to an empirical study of the regional economic growth level during the years of 2001 and 2011. Finally this paper makes related suggestions to the economic development of eight domestic economic regions.

Introduce

The economic development level of every region in China is in disequilibrium because there are variously economic and social differences in the growth rate and configuration mode of the production factors. For the issues above, the government has significantly improved the economic development levels of western and northeastern China, by refining and adjusting the regional development strategies like western development, Revitalizing old industrial base of northeastern China. But comparing with the other regions, there is still a great advantage in the developed regions of eastern and middle China because of their strong economic base. And the differences are still very obvious if we talk about the specific provinces, cities and autonomous regions. Comprehensive evaluation, analysis and comparison on the economic development levels of each region in China are of great significance to enhance the Macro-control and promote the coordinated development of national economy.

The domestic research about regional economic development is primarily in the 20th century, 90 years later. Most of the scholars adopt various statistics techniques to analysis the difference change law of regional economic [START_REF] Lu | Analysis the Levels of Development of the East[END_REF][START_REF] Feng | Exploratory Spatial Data Analysis of the Regional Economc Disparities in China[END_REF][START_REF] Shidai | Regional Economic Disparities and Coordination of Economic Development in Coastal Areas of Southeastern China[J][END_REF];DEA was used for evaluating the difference of regional economic development of 12 cities in Liaoning by liangjian and mojianfang [START_REF] Jie | The analysis of Regional Disparities Economic Development Based on DEA[END_REF][START_REF] Jianfang | The Application of DEA Method for Evaluating the Development of Region Economics[END_REF][START_REF] Zhuxin | Research on the Comprehensive Evaluation of Development of Economic Zone Ability Based on Set Pair Analysis-Around The Bohai Sea[END_REF];Yangzhuxin put forward those who be based on the collect bisect analyze to be able to evaluate the economic development of Bohai sea [START_REF] Zhuxin | Research on the Comprehensive Evaluation of Development of Economic Zone Ability Based on Set Pair Analysis-Around The Bohai Sea[END_REF]. Yuebing proposed a uniform approximation comprehensive evaluation method to estimate the level of economic development of 12 provinces and cities of china [START_REF] Bing | Study on the Comprehensive Evaluation Method of the Economic Development Level in China Areas[END_REF]. Existing research focus on difference analysis on regional economic development, there is little research that is directed to the change of regional economic development level for a period of time, For this reason the paper establish a set of complete scientific and comprehensive system of evaluation indicators, and proposes a dynamic comprehensive evaluation method based on three times weight, and then compared the economic development of 31 provinces, autonomous regions and municipalities during the years of 2001 and 2011, finally, the paper ranked the cities according to their economic development level.

Index selection

In according with the principle of systematic and comprehensive, reliability and easy to operate, an evaluation index system, which contains seven indexes, was established as shown in table 1:

A Dynamic Comprehensive Evaluation Method based on Three Times Weight

In the real world, data series which own large amount of data according to the order of time like a data cartridge, we call it multi-dimensional time series [START_REF] Yajun | Comprehensive Evaluation: Theory, Methods and Applications[END_REF][START_REF]Qian Xuesen.A New Discipline of Scienci-The Study of Open Complex Giant System and Its Methodology[END_REF], Dynamic comprehensive evaluation is a problem base on multi-dimensional time series, it generally denoted as:

1 2 1 2
( ) ( ( ), ( ), , ( ); ( ), ( ), , ( )),( 1,2, , ) The paper proposed a dynamic comprehensive evaluation method based on three times weight, the method follow the principle of greatest extends reflects the difference between the object as described in the following procedure: x are all extra-large, in order to combat the effects of different dimension and different type, need carry out the dimensionless treatment with the data as below:

i k k k m k i k i k im k y t f t t t x t x t x t k N     (1)
min / max min ( ) ( ) ( ) ( ( ) ( ) 1,2, , ; 1,2, , ; 1,2, , ) ij k ij k ij k ij k ij k x t x t x t i x t x t n j m k r       (2)
b)Determine the weight coefficients jk  of each year by using mean square error.

The basic principle of this method is the weight coefficient depend on the relative dispersion degree of the evaluation object, the greater the dispersion degree of index values, the greater the weight coefficient [START_REF] Yajun | Method of Dynamic Comprehensive Evaluation Based on Twice Driving [J[END_REF]. Therefore, the method reflects the importance of index by using mean square error, operation step as fellows:

1 ( ( )) ( ( )) jk jk m jk j R X t R X t     (3)
c)Determine the weight coefficient wj: If there were obvious difference between the index value of the xj at moment tk and the index value of the other moment, the weight at same time should play a biggish role in the process of evaluation in order to expose this difference. The fluctuant circumstance of index xj at moment tk(k=1,2,L,N) can be boiled down to a formula: cos ( ), ( )

1 j k j s sk jk x t x t N      (4)
The bigger the jk  , the index value at moment tk(k=1,2,L,N) closer to the index at other time, and the moment play a small role in the whole evaluation process, so the overall weight of the index j x can be expressed as:

1 11 1 1 N jk k jk mN j jk jk jk           (5)
The j  as a final weight value of index, the bigger the j  , the greater index influence, but rather the contrary.

3.2

Result based on the three stage weight dynamic comprehensive evaluation

When analyze the overall situation of i s , we expect the comprehensive evaluation value in the period of  

,

N tt of the bigger the better [START_REF] Wang | Multiple attribute decision making and sorting with maximizing deviations method[END_REF], but the fluctuation of i s in this period as small as possible.

a) Determine the synthetic evaluation indexes by using method based on twice-weighted. To determined the weight by using the method shows above, and built a synthesizing evaluation function at some point such as ( 1,2, , )

k t k N  : 1 ( ) ( ), 1,2, , ; 1,2, m i k j ij k j y t x t k N i n       (6)
The comprehensive evaluation value, is calculated from the above formula has direct comparability. i s has different 'performance' in different moment. During the study process on the execution status of the entire system, in order to embody the thinking about thick thin now thou and emphasize the differences between different moments, the comprehensive evaluation index is defined as [START_REF] Yajun | Comprehensive Evaluation: Theory, Methods and Applications[END_REF]  

1 exp ( ), 1,2, , N i k i k k h t y t i n     (7)
 is the time discount factor. In order to avoid the randomness of  value, it is defined that

1 (2 ) N    b)
Introduce the 'relatively balanced coefficient' to implement triple weighting. In the calculation process of comprehensive evaluation index, the situation like

() ij h h i j 
may happened because of the appearance of complementary. At this stage, the paper using the reciprocal of the coefficient of variation to describe the balance of the system:

1 i i n i i JH JH n JH         1 2 1 , ( 0) ,( 1, 2, , ) max ,( 0; 0) 1 1
i i i i d i d N i ik k N ik i k i h s s JH i n JH c s s h h N hh s N                    (8) (9)
Formula 8/9 shows that the bigger i JH , the smaller fluctuation of the system value, which means the system development is more balanced. Otherwise, the bigger fluctuation means the development is more imbalanced. We should increase the comprehensive evaluation value in some extent to encourage the system, which developed balanced. While for the system of lopsided development, we need to reduce their comprehensive evaluation value for punishment. c)An evaluation model based on relatively balanced coefficient. On the basis of getting relatively balanced coefficient, we make the aggregation once more: 12 ()

i i i h JH h       (10) 12 1 2 1 1 1 n ii i n i i JH h h           (11)
The i s is sorted from big to small according to the value of i h  . The sorting result reflects both the comprehensive evaluation result in each year. And meanwhile, the comprehensive evaluation result given from this method is completely based on the information provided by evaluation indexes.

Instance

The weight determination process based on the twice variance drive

To determine the weight for each economic index from the 31 provinces, cities autonomous regions from 2001-2011, we further discuss the change degree of the development trends from each economic index between different years (see table 2). The comprehensive evaluation values of each region from 2000 to 2010 are calculated by using linear weighted comprehensive method. The value is shown in table 4.

Introduce the relatively balanced coefficient to make triple weighting

Considering the fluctuation status of each province, city and autonomous region from 2001 to 2011, we calculate the relatively balanced coefficient and the overall evaluation. The ranking of overall evaluation values are shown in table 5:

Research Findings and Policy recommendations

As the overall evaluation result, the economic developments among the eastern, central and western China are very imbalanced. The developed areas mainly concentrate in eastern area while the undeveloped areas mainly concentrate in the western area. All of the provinces, cities and autonomous regions with top 10 economic development level are from the eastern area. On the contrary, 8 of the 12 regions from western area are in the last 10 places. The other 4 regions are Inner The economic development level of Liaoning province is always ranked at the 7th. The sequences of Tianjin, Inner Mongolia, Henan and Sichuan are stably rising up. In addition to Inner Mongolia, the rising rates of the other regions are very small. Besides, the changes of the regional economic status in China have the character like 'rigid body translation'. So it is very The southeast coastal area of China consists of Guangdong, Fujian and Hainan provinces. Unlike the development of eastern coastal area, the economic development of this area is very imbalanced. The comprehensive ranking of Guangdong province is No.1 while the ranking of Hainan province is only 26. So for these 2 backward provinces, especially for Hainan province, the major issue is how to utilize the overseas social resources and high-level openness from its neighbors Hongkong, Macao and Taiwan to accelerate the economic development.

The northern coastal area of China consists of 2 provinces (Hebei and Shandong) and 2 cities (Beijing and Tianjin). These 4 cities and provinces are always in steady development status (maximum ranking difference) during the 11 years. And finally, their comprehensive evaluation values are respectively ranked at the 6th, the 10th, the 9th and the 5th. This area should continue to utilize their superior geographical location, convenient transportation and developed technology, education and cultural undertakings, in order that, it can enlarge its opening to the outside world and seek progress in stability.

The middle reaches of the Yellow River in China consists of 3 provinces and 1 autonomous region, which are Shanxi, Shanxi, Henan and Inner Mongolia. It shows that the economic development levels of these 4 areas are improved year by year in this 11 years. Especially, the economic development level of Inner Mongolia has risen to the 13th in 2010 comparing with its 25th position in 2000. In these 4 regions, the economic development mainly relies on their rich natural resources. So, accelerating the steps to open to the outside world and adjust the economic structure become the major problem without any delay. And meanwhile, Shanxi, Shanxi and Henan provinces could take the development model of Inner Mongolia as reference to promote their big progress in economic development.

The middle reaches of the Yangtze River in China consist of Hubei, Hunan, Jiangxi and Anhui provinces, whose comprehensive ranking are in lower locations. This region should vigorously develop its agricultural production, increase the degree of opening to the outside world and accelerate industry transformation. Besides, because of the large population of this region, the effective improvement of per capita economic level is also the major task in its development.

The northeastern China consists of 3 provinces, which are Liaoning, Jilin and Heilongjiang. The major issues this region faces are resources depletion and the urgent requirement of industrial structure upgrading. So this region should increase the proportion of gross product from the non-public economics and the small and medium-sized business, speed up the technological progress and improve its capacity for independent innovation, consolidate the foundation position of agriculture, improve the resource utilization, promote the foreign economic cooperation and improve the usage quality of foreign investment. During the development progress, Jilin and Heilongjiang provinces could take the development process of Liaoning province as reference. They should deepen the collaboration between provinces and promote the integration development of regional economy.

Besides, the southwestern and northwestern China consists of 5 provinces and 1 city. Because of the historical existence and excessive enlargement of the development gap with eastern region, 90% of the regional economic development in this area belongs to underdeveloped region. The problems of this region such as remote location, poor soils, bad natural conditions and large number of poor people make the western region construction as a long and difficult task. The western development provides a series of policy guarantees and funding for the economic development of western China. So we must insist carrying out the western development strategy, accelerate the infrastructure construction, strengthen the ecological protection, positively adjust the industrial structure, develop the technology and education and accelerate the talent development. Under the premise of our country's stable increase in financial resources, our country should gradually increase the support on western region and fully encourage western region's initiatives, to push on the economic development of western region with specific target and phases.

3 . 1

 31 The weight determination process based on the twice variance drive a)Handling dimensionless. Without loss of generality, assume the index of index set 12 , , , m x x

Table 1 .

 1 Evaluation index system

	Index code Index

Table 2a .

 2a The calculations of index weights and change degree Based on the basic principle of twice variance drive, this paper reduces the economic indicator weights with the same development trends and increases the indicator weights of those with big changes. These paper determines the comprehensive weights for each kind of economic indicators like that shown in next table:

	Table 2b. The calculateions of index weights and change degree -The Average Cosine Value
		X1	X2	X3	X4	X5	X6	X7
	2001	0.995	0.970	0.963	0.983	0.996	0.967	0.983
	2002	0.996	0.978	0.963	0.990	0.997	0.968	0.985
	2003	0.997	0.983	0.933	0.993	0.998	0.973	0.989
	2004	0.997	0.984	0.962	0.995	0.998	0.976	0.991
	2005	0.997	0.983	0.965	0.994	0.998	0.980	0.991
	2006	0.997	0.985	0.953	0.994	0.998	0.982	0.991
	2007	0.997	0.985	0.961	0.995	0.998	0.983	0.992
	2008	0.997	0.983	0.968	0.995	0.998	0.981	0.992
	2009	0.997	0.981	0.954	0.994	0.998	0.974	0.990
	2010	0.996	0.981	0.968	0.993	0.997	0.965	0.985
	2011	0.996	0.975	0.968	0.990	0.995	0.959	0.983
		The Economic Index Weight of 2001-2011
		X1	X2	X3	X4	X5	X6	X7
	2001	0.167	0.130	0.134	0.137	0.139	0.164	0.129
	2002	0.173	0.124	0.113	0.144	0.142	0.169	0.136
	2003	0.164	0.127	0.136	0.140	0.135	0.169	0.129
	2004	0.164	0.130	0.128	0.148	0.134	0.170	0.128
	2005	0.169	0.125	0.126	0.156	0.134	0.162	0.128
	2006	0.149	0.128	0.145	0.157	0.136	0.149	0.136
	2007	0.150	0.131	0.141	0.154	0.137	0.151	0.136
	2008	0.149	0.134	0.134	0.156	0.137	0.157	0.133
	2009	0.153	0.136	0.124	0.155	0.140	0.158	0.133
	2010	0.149	0.135	0.130	0.153	0.139	0.157	0.138
	2011	0.148	0.143	0.129	0.149	0.141	0.153	0.136

Table 3 .

 3 Comprehensive weight values of every kind of economic indicators

		X1	X2	X3	X4	X5	X6	X7
	Weight	0.1558	0.1314	0.1342	0.1487	0.1358	0.1616	0.1324

Table 4a .

 4a Comprehensive evaluation of economic development in each region (2001-2011) Yunnan and Xinjiang, whose ranks are also in the backward places 18th, 13th, 19th and 20th respectively. For the 11 years development, the economic development level of Jiangsu province is always ranked at the 3rd place. The economic development level of Beijing city is always ranked at the 6th place.

	Regions	2001	2002	2003	2004	2005 2006 2007 2008 2009 2010	2011
	Beijing	0.44	0.46	0.47	0.47	0.47	0.53	0.52	0.53	0.51	0.51	0.53
	Tianjin	0.29	0.31	0.3	0.31	0.31	0.3	0.31	0.31	0.33	0.35	0.37
	Hebei	0.32	0.32	0.31	0.3	0.31	0.28	0.29	0.3	0.32	0.31	0.32
	Shanxi	0.12	0.11	0.12	0.13	0.14	0.15	0.15	0.16	0.18	0.17	0.18
	Inner
	Mongolia	0.11	0.11	0.13	0.15	0.16	0.17	0.2	0.22	0.25	0.27	0.28
	Liaoning	0.36	0.36	0.35	0.32	0.32	0.32	0.32	0.34	0.38	0.37	0.41
	Jilin	0.16	0.17	0.16	0.16	0.16	0.14	0.16	0.18	0.2	0.2	0.2
	Heilongjian
	g	0.23	0.24	0.23	0.22	0.21	0.17	0.16	0.17	0.19	0.18	0.19
	Shanghai	0.73	0.72	0.73	0.73	0.74	0.72	0.7	0.7	0.69	0.68	0.66
	Jiangsu	0.56	0.56	0.58	0.6	0.62	0.6	0.62	0.65	0.67	0.68	0.71
	Zhejiang	0.51	0.54	0.57	0.6	0.58	0.57	0.57	0.56	0.54	0.53	0.56
	Anhui	0.2	0.2	0.19	0.18	0.18	0.16	0.17	0.19	0.21	0.21	0.23
	Fujian	0.35	0.34	0.32	0.31	0.31	0.26	0.27	0.29	0.31	0.29	0.31
	Jiangxi	0.14	0.14	0.14	0.14	0.15	0.14	0.14	0.14	0.16	0.16	0.18
	Shandong	0.53	0.52	0.53	0.55	0.57	0.55	0.57	0.56	0.59	0.58	0.59
	Henan	0.27	0.27	0.27	0.27	0.28	0.27	0.29	0.3	0.33	0.32	0.33
	Hubei	0.28	0.28	0.28	0.26	0.24	0.2	0.21	0.23	0.25	0.24	0.26
	Hunan	0.24	0.23	0.23	0.21	0.22	0.21	0.21	0.22	0.24	0.24	0.25
	Guangdong 0.78	0.76	0.76	0.73	0.72	0.73	0.72	0.72	0.72	0.71	0.71
	Guangxi	0.14	0.14	0.14	0.13	0.13	0.12	0.13	0.13	0.16	0.15	0.16
	Hainan	0.09	0.09	0.08	0.08	0.07	0.06	0.06	0.06	0.08	0.06	0.07
	Chongqing	0.17	0.14	0.15	0.15	0.15	0.13	0.13	0.14	0.19	0.16	0.17
	Sichuan	0.24	0.26	0.26	0.25	0.24	0.22	0.22	0.24	0.26	0.27	0.29
	Guizhou	0.07	0.07	0.06	0.06	0.06	0.06	0.06	0.07	0.08	0.07	0.08
	Yunnan	0.17	0.14	0.14	0.13	0.14	0.12	0.12	0.12	0.13	0.13	0.14
	Tibet	0.03	0.03	0.1	0.06	0.06	0.04	0.02	0.02	0.02	0.01	0.01
	Shaanxi	0.13	0.13	0.13	0.13	0.13	0.13	0.14	0.15	0.18	0.18	0.2
	Gansu	0.08	0.08	0.07	0.06	0.06	0.06	0.06	0.07	0.08	0.07	0.07
	Qinghai	0.04	0.05	0.05	0.05	0.05	0.03	0.04	0.04	0.06	0.05	0.06
	Ningxia	0.04	0.05	0.04	0.04	0.05	0.05	0.06	0.06	0.09	0.08	0.09
	Xinjiang	0.14	0.14	0.14	0.13	0.12	0.11	0.11	0.11	0.13	0.11	0.13
	Mongolia, Sichuan,

Table 5 .

 5 The sorting result of the dynamic comprehensive evaluation result for each region's

	Regions	Relatively Balanced Coefficient Evaluation Value	Rank Results
	Beijing	0.950678	0.647108	6
	Tianjin	0.863093	0.401213	10
	Hebei	1.226271	0.431684	9
	Shanxi	0.615723	0.170316	25
	Inner Mongolia	0.407585	0.206644	18
	Liaoning	0.919504	0.448882	8
	Jilin	0.759644	0.208418	17
	Heilongjiang	1.737191	0.310575	14
	Shanghai	1.645028	1.109446	2
	Jiangsu	0.847437	0.791767	4
	Zhejiang	1.278549	0.792838	3
	Anhui	0.819529	0.236511	16
	Fujian	1.496676	0.456686	7
	Jiangxi	0.764263	0.177665	22
	Shandong	1.014575	0.743778	5
	Henan	0.844111	0.366211	11
	Hubei	1.302635	0.351772	12
	Hunan	1.017027	0.297138	15
	Guangdong	1.56975	1.125752	1
	Guangxi	0.851985	0.173828	23
	Hainan	1.314329	0.098503	26
	Chongqing	0.82172	0.185603	21
	Sichuan	0.93464	0.321178	13
	Guizhou	0.776897	0.078473	28
	Yunnan	1.537235	0.198961	19
	Tibet	0.251214	0.031996	31
	Shaanxi	0.580093	0.170543	24
	Gansu	1.107278	0.088641	27
	Qinghai	0.64729	0.052347	30
	Ningxia	0.422798	0.061456	29
	Xinjiang	1.675251	0.19069	20
	difficult to break the existed economic pattern because of the forming from a lot of
	years.