Hop is mainly designed for programming small- to medium- sized interactive applications across the web. It is designed as a general-purpose web programming language which targets applications such as electronic agendas, photographs browsers, music players, mailer clients, operating system administration tools, and so on. In addition to enabling programming distributed applications over the web, Hop is also convenient for implementing applications that run on a single computer, on behalf of a single user. In that particular case, Hop is considered as a replacement for traditional graphical toolkits.

In contrast with most web-oriented languages and frameworks such as PHP and Ruby On Rails, the design of Hop is not database-centric. That is, while its standard library provides APIs for managing databases, Hop is not specially tuned for programming applications that access databases via the web. Hop is designed for programming various kinds of applications that need graphical user interfaces amongst which some might access databases.

Hop follows the path opened by Tcl/Tk, Java/Swing, or C/GTK+ but it differs from its ancestors by enforcing a strict separation between the programming of the interface from the programming of the logic of the applications. For that, it exposes a dual core execution model where one core executes the computations needed by the logic of the program while the second core executes the computations needed by the graphical interface. We have deliberately provided Hop with a stratified language approach in order to emphasize the duality of these programs. However Hop tightly links the code of the interface and the code of the logic:

• it packages a whole application in a single location (e.g. a file).
• it supports function calls that traverse the strata.
• it supports data exchange between the strata.

Hop helps programming web applications because:

• it eases the deployment of applications by hiding URLs and by packaging the components of an application in a single place.
• it simplifies the control flow of the web application by allowing symmetric communications that can be initiated by both ends.
• it supports efficient event loops that avoid busy waiting.
• it eases the communication between servers and clients by supporting transparent function calls and partially shared name spaces.
• it provides a library of pre-defined widgets.
• it allows users to implement their own set of widgets that can be combined with the standard library for implementing complex GUIs.

The paper is organized as follows. Section Overall language design2 informally presents the stratified language design. Section The HOP dual syntax3 presents its syntax. The following Section The HOP dual evaluation4 presents its semantics. It zooms in the function calls, and it presents the Hop's event loop. Section Example5 presents an example of Hop programming. It shows a simplistic IMAP web client. Section Implementation6 sketches the current implementation of Hop. Section Discussion and Related work7 presents related work and envisions future work.

Hop fosters a model where the main computation of an application is executed on a server and the graphical user interface is executed on remote clients. From the user point of view, a Hop program is executed within a web browser and it is associated with a well known URL. Once the program starts, the server and the clients continuously communicate. The exchanges are implemented by remote function calls and event loops. Hop is well suited for implementing applications that need frequent communications between the server and the client. For instance, we have implemented a music player with Hop that continuously displays, on the client, the elapsed time of the songs played on the server. On that particular application, as with many others we have implemented with Hop, the server and the client are frequently hosted by the same physical computer.

A Hop program is executed simultaneously on several engines. The main engine is dedicated to executing the logic of the program. It executes CPU demanding computations and operations that require system privileges for accessing files or other resources. The other engines, henceforth called GUI engines, are dedicated to executing actions related to the programming of the graphical user interfaces. Engines are mapped to actual physical computers. More than one engine can be mapped to a single computer.

When a Hop program starts, it first executes on the main engine. This elaborates the description of a graphical user interface that is sent to a GUI engine. From that moment, the execution flows from the GUI engine to the main engine and vice versa. The GUI engines may invoke services from the main engine by the means of function calls. The main engine may signal events to the GUI engines. Each event carries an identity and a value. Events are handled asynchronously. They are used by the main engine to notify GUI engines when a new information is available. They are a means for implementing pushing on the web.

Hop is a stratified language. The first stratum is dedicated to programming the main engines, or the servers. The second stratum is dedicated to programming graphical user interfaces, or the clients.

Both strata provide different facilities. On the one hand, the main stratum provides an API for accessing the file system and the other resources of the computer that hosts it, but it does not support any facility for handling graphical user interfaces. On the other hand, the GUI strata is provided with a full set of functionalities for dealing with graphical interactions but it has drastically restricted accesses to the resources of the computer it executes on. Because they are using different APIs, in general, an expression of the main stratum cannot be executed on the client and vice versa.

As presented in Section The HOP dual syntax3, Hop uses a compact syntax that is close to the syntax used in traditional XML authoring. However, it is a complete programming language that subsumes many web technologies. As such, it allows the implementation of libraries that can be combined for implementing complex applications.

For the sake of the example and to give an intuition of what Hop programming looks like, here is a complete Hop program:

(let ((def (<DIV> ""))
      (svc (service (w)
              (<P> (sql-exec db "SELECT * FROM dict WHERE (def=~a)" w)))))
   (<HTML>
      (<BODY>
         (<TABLE>
            (<TR>
               (<TD> "search")
               (<TD> (<INPUT>
                        :type "text"
                        :onkeyup ~(with-hop ($svc this.value)
                                     (lambda (h)
                                        (set! $def.innerHTML h))))))
            (<TR>
               (<TD> :colspan 2 def))))))
                  

This program acts similarly to Google/suggest. The client displays an input box. It interactively reacts to key press events. Each time a new character is entered, the client invokes a service on the server which searches in a database the definition of the word sent by the client. On success, the definition is displayed back in the client display. The most important part of this example is the with-hop construction that invokes, from the client, a function located on the server. It is detailed in Section HOP services4.3

At first glance, the syntax of the main stratum of Hop is a mere variation around HTML involving superficial modifications. It merely introduces an extra open parenthesis before any markup and replaces the closing markup with the single closing parenthesis. It also encloses string literals within " characters. Therefore, the HTML expression:

<HTML>
   <BODY>
      <B>A plain text</B>
   </BODY>
</HTML>

is written in Hop, as:

(<HTML>
   (<BODY>
      (<B> "A plain text")))

In Hop, attributes are introduced by an identifier starting with a colon character (:) and their value is separated from the name by white spaces. Hence the corresponding Hop program of the HTML document of Figure 1 is written as in Figure 2.

<HTML>
   <BODY>
      <TABLE width="100%">
         <TR> <TD>0</TD></TR>
         <TR> <TD>1</TD></TR>
         <TR> <TD>2</TD></TR>
         <TR> <TD>3</TD></TR>
      </TABLE>
   </BODY>
</HTML>

In spite of the strong resemblance, there is a very important difference between the semantics of the two sources. While the HTML source can be interpreted as the external representation of a tree, the Hop source is actually a computer program that can be evaluated in order to produce a document. This is detailed in Section The HOP dual evaluation4.

(<HTML>
   (<BODY>
      (<TABLE> :width "100%"
         (<TR> (<TD> 0))
         (<TR> (<TD> 1))
         (<TR> (<TD> 2))
         (<TR> (<TD> 3)))))

The GUI stratum is composed of GUI expressions. They are nested inside main expressions. The "~" character escapes from main expressions to GUI expressions. The GUI expressions are usually used as values of attributes, as can be seen in the following example:

(<HTML>
   (<BODY>
      (<BUTTON>
         :onclick ~(alert (* (Math.atan 1) 4))
         "Click me to see an approximation of PI")))

The character "$" escapes from the GUI stratum back to the main stratum. That is, it introduces an expression of the main stratum inside an expression of the GUI stratum. There is no limit to the nesting level so these main stratum expressions may, in turn, use the "~" character to escape back to the GUI stratum. For the sake of the example, let us consider a re-writing of the previous example where the approximation of π is moved to the main stratum:

(<HTML>
   (<BODY>
      (<BUTTON>
         :onclick ~(alert $(* 4 (atan 1)))
         "Click me to see an approximation of PI")))

Note that these two programs are likely to show different approximations since no provision is taken to guarantee that the precision of the arithmetic of the main stratum and the precision of the GUI stratum are the same.

The execution of a Hop program differs from the execution of traditional computer programs. In order to be executed, a Hop program has to be first loaded on a HOP server. This server conforms to the HTTP protocol [4]. It binds the program to an URL provided by the administrator of the server. This URL is used by clients (i.e. web browsers) to start the program.

A Hop program constructs a response to an HTTP request. In general, this response is a XML document but in some situations it can be any other data structures. For the sake of simplicity, in this paper, we focus on HTML responses only but all the presented techniques also directly apply to XML.

The execution of a Hop program is distributed. One part is executed on the server which evaluates the expressions of the main stratum. The second part is executed on the client which evaluates the expressions of the GUI stratum. In general the execution flow switches from a server to a client and vice versa but Hop also allows two (or more) execution flows to run in parallel. The client communicates with the server via remote function calls. The server communicates with the client via signals. Both communication means allow compound values to be carried.

The purpose of most Hop programs is to build HTML pages that are visualized by web browsers. The phase of the execution on the server where the HTML pages are constructed is called elaboration. It takes place before any execution can start on the client.

Hop implements HTML pages as trees. The Hop libraries of the two strata provide functions for constructing and manipulating them. In both strata, the trees are first class values. Hence, they can be passed as argument to functions, returned as results, and stored into data structures and variables. For the sake of the example, Figure 3 is a re-writing of the Hop program presented Figure 2 where the four rows of the table are bound to local variables.

(let ((row0 (<TR> (<TD> 0)))
      (row1 (<TR> (<TD> 1)))
      (row2 (<TR> (<TD> 2)))
      (row3 (<TR> (<TD> 3))))
   (<HTML>
      (let ((table (<TABLE> row0 row1 row2 row3)))
         (<BODY> table))))

The interest of such an approach is better understood when some abstraction is used. In the example of Figure 4 a function is defined for automating the construction of the rows of the table.

(define (<ROW> v)
   (<TR> (<TD> v)))

(<HTML>
   (let ((table (<TABLE> (<ROW> 0) (<ROW> 1) (<ROW> 2) (<ROW> 3))))
      (<BODY> table)))

Note that the Hop convention is to surround the name of the functions that build HTML trees by the < and > characters and to use upper case letters. This example implicitly unveils that Hop standard HTML markups are implemented as regular functions. It also shows that defining a new markup in a user program is no more complex than defining a function.

As presented in Section The syntax of the GUI stratum3.2, any expression of the main stratum can be nested in an expression of the GUI stratum after an escaping $ character. At elaboration time, the escaping main stratum expressions are evaluated and the resulting values are injected in the response. In consequence, when the response is shipped to the client it is totally stripped of main stratum expressions. Let's consider the Hop source of Figure 5 before elaboration.

 1: (define x "out") 
 2: (define y (vector 1 2 3)) 
 3: 
 4: (<HTML>
 5:    (<BODY>
 6:       (<SCRIPT> ~(define x 0)) 
 7:       (<P> :onmouseover ~(begin
 8:                             (set! x (+ 1 x))
 9:                             (alert "over=" x)) 
10:            :onmouseout (alert $x) 
11:            :onclick (alert $y) 
12:            "foo")))

Reflecting the two different execution times, the two strata use separate name spaces. A variable from the main stratum and a variable from the GUI stratum can hence hold the same name without conflicting. In other words, the variables defined line 1 and line 6 of Figure 5 are different. The elaboration phase replaces the occurrences of the variable x that belongs to the main stratum line 10 with the value "out" but it leaves the variable x that belongs to the GUI stratum line 9 as shown in Figure 6.

 4: (<HTML>
 5:    (<BODY>
 6:       (<SCRIPT> ~(define x 0))
 7:       (<P> :onmouseover ~(begin
 8:                             (set! x (+ 1 x))
 9:                             (alert "over=" x))
10:            :onmouseout ~(alert "out")
11:            :onclick ~(alert '#(1 2 3))
12:            "foo")))

As it can be seen here, the variable y which is bound to a Hop vector in Figure 5, line 2 is replaced with a constant vector in Figure 6, line 11. This shows that the elaboration can inject complex data structures in the response. In particular it can inject tree branches that are under construction. This is illustrated by the next example that shows that an HTML tree can be used when constructing a document in the main Hop program (line 5 of Figure 7) and can also be injected in the GUI stratum (line 7). The following example constructs an HTML page that swaps the two items of the unordered list each time the button is clicked.

 1: (let ((el (<UL> (<LI> "foo") (<LI> "bar"))))
 2:    (<HTML>
 3:       (<HOP-HEAD>)
 4:       (<BODY>
 5:          el
 6:          (<BUTTON>
 7:             :onclick ~(let* ((nodes (dom-child-nodes $el))
 8:                              (a (array-ref nodes 0))
 9:                              (b (array-ref nodes 1)))
10:                          (dom-append-child! $el (dom-replaceChild a b)))
11:             "swap me"))))

This section presents one of the main technical novelty brought by Hop, namely the Hop remote services.

(<HTML>
   ;; a link to google portal
   (<A> :href "http://www.google.com" "Google Portal")
   ;; a google request
   (<FORM> :action "http://www.google.com/search"
           (<INPUT> :type "text" :name "q" :value "")
           (<INPUT> :type "submit" :name "btnG" :value "search")))

   unit → HTMLtree

   string → HTMLtree

   (define-service (<ident> <ident>0 ...)
      <expression>)

 1: (define-service (portal) 
 2:    ;; produce a web page containing a big lambda character
 3:    (<HTML>
 4:       (<BODY>
 5:          (<CENTER> (<B> (<BIG> (<BIG> (<BIG> (<BIG> "&#955;")))))))))
 6: 
 7: (define-service (rev q) 
 8:    ;; produce a web page made of the reverse of the argument
 9:    (<HTML>
10:       (<BODY>
11:          (<CENTER> (<B> (list->string (reverse (string->list q))))))))
12: 
13: (<HTML> 
14:    ;; a link to our Hop portal
15:    (<A> :href portal "portal") 
16:    ;; a HOP request
17:    (<FORM> :action rev 
18:            (<INPUT> :type "text" :name "q" :value "")
19:            (<INPUT> :type "submit" :name "btnG" :value "reverse")))

   (service (<ident>0 ...)
      <expression>)

 1: (let loop ((items (list "foo" "bar" "gee"))) 
 2:    (<HTML>
 3:       (<BODY>
 4:          (<H3> "To do list")
 5:          (<FORM> 
 6:             :action (service (new) (loop (cons new items))) 
 7:             (<INPUT> :name "new" :type "text" :size 40) 
 8:             (<INPUT> :type "submit" :value "add new item")) 
 9:          (<TABLE>
10:             (map (lambda (item)
11:                     (<TR>
12:                        (<TD> item)
13:                        (<TD> (<FORM> 
14:                                 :action (service () (loop (delete! item items)))
15:                                 (<INPUT> :type "submit" :value "remove")))))
16:                  items)))))

  (with-hop (service arg0 ...)
     [(lambda (h) ...success expression...)
      [(lambda (h) ...failure expression...)]])

1: (define-service (server-date)
2:    (current-date))
3: 
4: (<HTML>
5:   (<BUTTON>
6:      :onclick ~(with-hop ($server-date) (lambda (h) (alert h)))
7:       "Server time"))

 1: (define-service (add10 lst)
 2:    (<TABLE>
 3:       (<TR>
 4:          (map (lambda (e) (<TD> (+ 10 e))) lst)))))
 5: 
 6: (<HTML>
 7:    (<HEAD> (<HOP-HEAD>))
 8:    (let ((el (<DIV> "")))
 9:       (<BUTTON>
10:          :onclick ~(with-hop ($add10 (list 1 2 3))
11:                       (lambda (h)
12:                          (set! $el.innerHTML h)))
13:          el)))

 1: (define-service (add10 lst)
 2:    (map (lambda (e) (+ 10 e)) lst))
 3: 
 4: (<HTML>
 5:    (<HEAD> (<HOP-HEAD>))
 6:    (let ((el (<DIV> "")))
 7:       (<BUTTON>
 8:          :onclick ~(with-hop ($add10 (list 1 2 3))
 9:                       (lambda (h)
10:                          (let ((t (<TABLE> (<TR> (map <TD> h))) ))
11:                             (dom-remove-child!
12:                              $el (array-ref (dom-child-nodes $el) 0))
13:                             (dom-append-child! $el t))))
14:          el)))

(with-hop :host "http://remote.host:8080" ($server-date)
   (lambda (h) ...))

(with-url "http://www.inria.fr/"
   (lambda (h) (xml-parse h ...)))

Hop provides two different kinds of event loops. The first ones are used to initiate, in the GUI stratum, computations at regular time intervals. Since, they are roughly equivalent to the JavaScript timer facilities, we only present them with the example shown Figure 13. This program polls every five seconds the server time which is updated on the client display.

 1: (<HTML>
 2:    (<HEAD> (<HOP-HEAD>))
 3:    (<BODY>
 4:       (let ((clock (<DIV> "")))
 5:          (<TIMEOUT-EVENT>
 6:             :timeout 5000
 7:             :handler ~(with-hop ($(service () (current-date)))
 8:                          (lambda (h)
 9:                             (set! $clock.innerHTML h)))
10:             clock))))

Hop also provides an event mechanism which prevents client to busy wait. These events are first declared on the server, that is in the main stratum of a Hop program. In the GUI stratum, clients register to these events by the means of the dedicated markup <HOP-EVENT>. When a server emits an event, registered clients are notified. The implementation of <HOP-EVENT> liberates clients from checking periodically event notifications. This is, to our knowledge, another technical innovation brought by Hop.

Events are instances of the hop-event class. The function of the main stratum that signals an event has the following prototype:

   signal-hop-event!: event × <value> → unit

The markup <HOP-EVENT> has the following shape:

(<HOP-EVENT>
   :event a-hop-event
   :handler a-client-code)

For the sake of the example, let us study a variation over the example of Figure 13. In this second version, the server initiates the communication with the client. That is, the client does not explicitly poll the server. It displays the server time when the server signals the event.

 1: (define evt (instantiate::hop-event (name "server time event"))) 
 2: 
 3: (thread-start! 
 4:  (make-thread
 5:   (lambda ()
 6:      (let loop ()
 7:         (sleep! 5000)
 8:         (signal-hop-event! evt (current-time))
 9:         (loop)))))
10: 
11: (<HTML>
12:    (<HEAD> (<HOP-HEAD>))
13:    (<BODY>
14:       (let ((clock (<DIV> "")))
15:          (<HOP-EVENT>
16:             :event evt
17:             :handler ~(set! $clock.innerHTML event) 
18:             clock))))

At Line 3 a thread is spawned on the server. This thread pauses during 5 seconds and then signals the event evt defined in line 1. The form instantiate creates an instance of the class hop-event. The event is intercepted on the GUI stratum in line 17. In the :handler block, following the JavaScript tradition of event handling, the variable event is automatically bound to the event that has been intercepted. The content of the clock <DIV> is replaced with the value carried by the event.

One may object that we have not eliminated the busy wait but moved it to the server. While, undubitably true, this is not a weakness of Hop. The point of this example is to show that clients may avoid busy waiting server events using the <HOP-EVENT> markups. It is up to the server to implement the appropriate signaling mechanism. The point of this section is only to show that the Hop notification implements a server push method.

Hop is currently implemented as a web server. It accepts HTTP requests and it selects, according to the URL, the appropriate treatment to execute. Services are implemented as couples containing one function and one URL. That is, each time a service (anonymous or not) is created, a new unique URL is generated, a new function is created and the couple {URL, function} is stored inside a table on the server. When a request is intercepted, this table is scanned for selecting the appropriate service to execute. When a service is used in the GUI stratum, a reference to it is compiled to JavaScript. At last, expressions of the GUI stratum are compiled on the fly to JavaScript by a Hop-to-JavaScript compiler whose description is out of scope of this present paper. Let us assume the following Hop expression:

(<BUTTON>
    :onclick ~(with-hop ($(service (x y) (+ x y)) 1 2)
                 ...)
    "Click this link")

The elaboration yields the following HTML document:

<BUTTON onclick='with_hop(
  function() {
    return hop_service_url("/hop/???/4-57604278",
                           ["x", "y"],
                           arguments )
  }(1, 2), ...)'>
  "Click this link"
</BUTTON>

The dynamically created URL /hop/???/4-57604278 is the unique identifier associated with the service. The current implementation of Hop is not able to reclaim these URLs. That is, it keeps alive for ever all the services and their URLs. It never collects URLs because we don't think that it exists a universal criterion allowing URL reclaim. Obviously, we could adopt a solution based on time stamping. For instance, we could arbitrarily decide to collect URL after two or three hours. We are reluctant to adopt such a solution but we are aware that this weakness has to be overcome in the future versions of Hop. We are investigating a solution where the server functions representing the services are encoded in the URL. More precisely according to this solution it would be no longer necessary to store the whole function on the server. Instead, only the closure environment would be encoded and sent to the client (i.e. the lexical environment active when the service was created). If this approach succeeds, it will remove the need for the table which binds URLs to functions.

The JavaScript functions with_hop and hop_service_url are defined in the standard Hop GUI stratum library. They are shipped with every generated page. As presented in Section HOP service calls4.3.2 the form with-hop calls asynchronously a service. It can be defined as:

function with_hop( service, success, failure ) {
 function callback( h ) {
  if( h.status == 200 ) 
    if(h.getAllResponseHeaders().indexOf("hop-json")>=0)
      return success( eval( h.responseText ) );
    else
      return success( h.responseText );
  else 
    return success( h );
 };
  
 return hop( service, callback, failure );
}

The function hop_service_url maps a service to a URL. It could be implemented as:

function hop_service_url( service, formals, args ) {
   var len = formals.length;

   if( len == 0 ) {
      return service;
   } else {
      var url = service + "?hop-encoding=hop";
      var i;

      for( i = 0; i < len; i++ ) {
         url += "&" + formals[ i ] + "=" + hop_serialize( args[ i ] );
      }

      return url;
   }
}

The function hop_serialize marshals JavaScript values in a format compatible with the main stratum of Hop. When the server sends a value to the client which is not an HTML tree, it adds a hop-json header in the message and it uses the JSON external format that the client simply decodes with the JavaScript eval function call. The library function hop, whose code is not presented here, actually performs the JavaScript asynchronous call. It uses ad-hoc technics which are dependent of the clients web browsers.

The current implementation of the <HOP-EVENT> markup relies on services invocation. Waiting for an event is implemented as invoking an asynchronous service that returns only when the event is emitted from the client. More precisely, when an event e1 is created, the server automatically generates a service svc_e1. The markup <HOP-EVENT> is compiled, during the elaboration stage, as an invocation of svc_e1 (see Section HOP service calls4.3.2). This call completes when the server emits the signal e1. At that time, the client receives the value associated with the event. It re-invokes the service svc_e1 for waiting for other values and, in parallel, it handles the received value. Assuming the library function hop_event whose definition looks like:

function hop_event( event, event_handler ) {
  var http = new XMLHttpRequest();
  var url = "hop_event_wait?event=" + event;

  http.open( "GET", url, true );
  http.onreadystatechange = function() {
    if( http.readyState == 4 && http.status == 200 ) {
       // invokes the user handler
       event_handler( http );
}

       // recursively call the function in 
       // order to wait new results
       hop_event( event, event_handler );
    }
  }
  http.send( null );
}

The actual implementation takes care of portability issues. The expression (<HOP-EVENT> evt handler) is then compiled to:

 
hop_event( evt, handler );

This implementation prevents the client from busy waiting events for the server because invoking a service using an XMLHttpRequest is an asynchronous operation that does not involve polling. Surprisingly, this simple technique appears to be robust and it allows to implement passive wait on the client quite easily. It has been suggested by Marc Feeley who deserves most of its credit.

Hop embraces in one unique language all the facets of web programming. It emphasizes compactness of programs and interactivity of applications. It proposes a lightweight approach based on functional programming. By contrast to previous studies, it does not enforce an interaction model based on forms submissions [7,6]. It follows an opposite direction to previous studies that aimed at easing CGI programming in traditional programming languages. The Meijer's CGI library [11] is a functional representative of this kind. Hop also distinguishes from early works such as the <bigwig> project [13,1] that are aimed for larger web applications where sessions, database integration, security, static checking of dynamic web pages, and concurrency are important issues. Hop proposes a solution for authoring web pages, programming the interactions between the servers and the clients, and programming the reactions of the user interfaces. In that sense, it is unrelated to languages such as Mozilla's XUL or Microsoft XAML that focus on the programming of the clients. XUL is the programming language of Mozilla which is, in addition to being a web browser, a whole execution environment. Hop is independent of any browser. It is used for implementing applications that need server- and client- programming. It can also be used for implementing applications that execute totally on a server. For instance, it can be used for implementing servers delivering music or for implementing tunneling via HTTP. This kind of applications is out of scope of languages such as XUL.

One of the closest works to Hop is due to Philip Wadler and his colleagues. The Links¹ programming language shares the goal of Hop. Like Hop, Links is a functional language that manages transparent function calls across the web. As Hop a Links program is made of a single source file. Like Hop, the client codes are compiled to JavaScript. However, contrary to Hop, Links does not allow server codes and client codes to be interleaved. Links uses only one name space and functions are annotated with client or server marks depending on where they execute. This solution is elegant because it allows the use of only one single syntactic construction for calling either client functions and server functions. The Hop expression:

(with-hop ($lookup n) (lambda (lst) ...))

in Links is nicely written:

lst <- (lookup n); ...

However, we think that this approach has several weaknesses. First, we think that it is important to reflect, in the syntax, that calling a server function is a different operation from calling a client function. The two kinds of calls have totally different implementation and execution costs. Another weakness is that the Links approach gives the illusion that programming the client and programming the server is the same. However, the two execution engines cannot support the same set of operations. Some operations are meaningless on the server and vice versa (for instance, getting the dimension of the graphical user interface window is meaningless on the server). Next, we think that the elaboration stage of Hop that allows to inject server values in the client code is a strength. We hope that the various examples of the paper are demonstrative enough. The last difference between Links and Hop is the event loops (see Section HOP Event loops4.4) that have no counter part in Links.