DOCSLIB.ORG

Ocsigen, a Web Programming Framework

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ocsigen, a Web Programming Framework Experience Report: Ocsigen, a Web Programming Framework Vincent Balat Jer´ omeˆ Vouillon Boris Yakobowski Laboratoire Preuves, Programmes et Systemes` Universite´ Paris Diderot (Paris 7), CNRS Paris, France fvincent.balat, jerome.vouillon, [email protected] Abstract Web programming is highly constrained by technology (pro- The evolution of Web sites towards very dynamic applications tocols, standards and browsers implementations). Commonly used makes it necessary to reconsider current Web programming tech- Web programming tools remain very close to this technology. We nologies. We believe that Web development would benefit greatly believe that Web development would benefit a lot from higher level from more abstract paradigms and that a more semantical approach paradigms and that a more semantical approach would result in would result in huge gains in expressiveness. In particular, func- huge gains in expressiveness. tional programming provides a really elegant solution to some im- It is now widely known in our community that functional pro- portant Web interaction problems, but few frameworks take advan- gramming is a really elegant solution to some important Web in- tage of it. teraction problems, as it offers a solution to the statelessness of the The Ocsigen project is an attempt to provide global solutions HTTP protocol (Queinnec 2000; Graham 2001; Hughes 2000). But this wisdom has not spread in the Web programming community. to these needs. We present our experience in designing this general 1 framework for Web programming, written in Objective Caml. It Almost no major Web framework is taking advantage of it. We provides a fully featured Web server and a framework for program- believe the reason is that functional programming has never been ming Web applications, with the aim of improving expressiveness fully exploited and that one must be very careful about the way it is and safety. This is done by taking advantage of functional program- integrated in a complete framework in order to match precisely the ming and static typing as much as possible. needs of Web developers. The Ocsigen project is trying to find global solutions to these Categories and Subject Descriptors D.1.1 [PROGRAMMING needs. In this paper, we present our experience in designing Ocsi- TECHNIQUES]: Applicative (Functional) Programming; H.3.5 gen, a general framework for Web programming in Objective Caml [INFORMATION STORAGE AND RETRIEVAL]: Online Informa- (Leroy et al. 2008). It provides a full featured Web server and a tion Services—Web-based services framework for programming Web applications, with the aim of im- proving expressiveness and safety. This is done by taking advantage General Terms Design, Languages, Reliability, Security of functional programming and static typing as much as possible Keywords Ocsigen, Web, Networking, Programming, Implemen- (Balat 2006). tation, Objective Caml, ML, Services, Typing, Xhtml This paper is a wide and quick overview of our experience regarding this implementation. In section 2, we describe our use 1. Introduction of functional programming. In section 3, we show how some very strong correctness properties can be encoded using Ocaml’s type In the last few years, the Web has evolved from a data-centric plat- system. Finally, in section 4, we describe the implementation of a form into a much more dynamic one. We tend now to speak more concrete Web application using our solutions. and more of Web application, rather than Web sites, which hints that the interaction between the user and the server is becoming much more complex than it used to be. 2. Functional Programming for the Web What is striking is that this evolution has not been induced, nor even followed, by a corresponding evolution of the underlying The Ocsigen project provides a Web server written in Objective technology. The RFC specifying the version of the HTTP protocol Caml. This server offers all the features one would expect from a currently in use dates back to 1999 and current HTML looks very general purpose Web server, starting with a comprehensive support much like the one we were using ten years ago. The main change of the HTTP 1.1 protocol (Fielding et al. 1999) (including range is probably the increasing use of JavaScript, mainly due to imple- requests and pipelining). Data compression, access control and mentation improvements, which made possible the advent of a new authentication are all supported. The server is configured through kind of Web applications. flexible XML-based configuration files. The server is designed in a modular way. It can therefore be extended very easily just by writing new modules in Ocaml. Among the modules currently available are a module for running CGI scripts, a reverse proxy (which makes it easy to use Ocsigen with Permission to make digital or hard copies of all or part of this work for personal or another Web server), a filter to compress contents, etc. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation In the remainder of this section, we highlight the concurrency on the first page. To copy otherwise, to republish, to post on servers or to redistribute model used for the Web server implementation, and then our main to lists, requires prior specific permission and/or a fee. ICFP’09, August 31–September 2, 2009, Edinburgh, Scotland, UK. Copyright c 2009 ACM 978-1-60558-332-7/09/08. $5.00 1 A notable exception being Seaside (Ducasse et al. 2004). 311 extension to the server, that is, Eliom, a framework for writing Web let srv = register_new_service applications in Ocaml. ~path:["bar"] ~get_params:unit 2.1 Cooperative Threads f A Web server is inherently a highly concurrent application. It must The first argument (labelled ~path), corresponds to the path in the be able to handle simultaneously a large number of requests. Fur- URL to which the service will be bound. The second argument thermore, composing a page may take some time, for instance when (labelled ~get_params) describes URL parameters (here none, as several database queries are involved. The server should not to be this service does not expect any parameter). The function f is used stalled in the meantime. We have chosen to use cooperative multi- to produce the corresponding page. threading to address this issue. Indeed, cooperative threads make Inside Eliom, one can generate an anchor linking to this service it possible to write multi-threaded code while avoiding most race by applying the HTML anchor constructor a to the service srv, conditions, as context switches only occur at well-specified points. the current service context sp (which contains in particular the Between these points, all operations are executed atomically. In current URL, and is used to construct relative links), the text of the particular, it is easy to use safely shared mutable datastructures, anchor anchor_contents and the unit value () corresponding to such as hash tables, without using any lock. the absence of parameters. We use the Lwt thread library (Vouillon 2008), which provides a srv sp anchor contents () a monadic API for threads. With this library, a function creating a Web page asynchronously will typically have type: Note that the service URL can be changed just by modifying the path at a single location in the source code, and all links will remain unit ! html Lwt.t: correct as they are computed automatically. It returns immediately a promise (sometimes also called future) of Several services can share the same URL, for instance when type html Lwt.t, that is, a value that acts as a proxy for the value they expect different parameters. This means that a service will of type html eventually computed by the function. Promises are a not respond if some of its arguments are missing or ill-typed, monad. The return operator of the monad has type: avoiding a whole class of hard-to-detect errors.2 More generally, 'a ! 'a Lwt.t: a full range of service kinds is provided, allowing to describe precisely how services are attached to URLs. This makes it possible It creates an immediately fulfilled promise. The bind operator has to describe very flexible and precise Web interactions in just a few type: lines of code. A service can be associated to a path (and possibly parameters), to the value of a special parameter, or to both or them. 'a Lwt.t ! ('a ! 'b Lwt.t) ! 'b Lwt.t: The choice of the right service to invoke is performed automatically by Eliom. It takes as arguments a promise and a function to be applied to Services can be dynamically created in response to previous the value of the promise when it becomes available. The promise interactions with the user. Their behavior may depend for instance returned by the operator gives access to the value eventually com- on the contents of previous forms submitted by the user or the puted by the function. This operator can be used for sequencing result of previous computations. This is implemented by recording asynchronous operations, as well as for synchronization (for wait- the behavior associated to the service as a function closure in a ing for the completion of some operation before performing further table on the server. This is an instance of continuation-based Web operations). programming (Queinnec 2000; Hughes 2000; Graham 2001), This In order to make it possible to use third-party non-cooperative is known to be a really clean solution to the so-called back button libraries, Lwt also allows to detach some computations to preemp- problem, but is provided by very few Web frameworks. tive threads. It is also possible to classify services with respect to the type of the value they return.
Load more

Recommended publications
  • PPS Activity Report 2007-2012
    PPS Activity Report 2007-2012 Laboratoire Preuves, Programmes, Syst`emes, UMR 7126 Universit´eParis Diderot and CNRS March 1, 2013 Contents 1 General presentation, objectives and results 2 1.1 Themes ........................................... 3 1.2 Milestones .......................................... 7 1.3 Structure and scientific organization of the PPS lab ................... 9 1.4 Scientific animation ..................................... 11 1.5 Funding ........................................... 12 1.6 Evolution of the composition and recruitment policy .................. 13 1.7 Summary of results ..................................... 16 1.8 Conclusion ......................................... 17 2 Theme: Proofs and Types 17 2.1 Lambda-calculus and extensions ............................. 17 2.2 Subtypes and intersection type for XML data processing ................ 18 2.3 Rewriting and security ................................... 19 2.4 Development of the Coq system .............................. 19 2.5 Formalization in Coq and in other proof assistants ................... 21 2.6 Certification of cost annotating compilers ........................ 22 2.7 Dependent types ...................................... 22 2.8 Classical logic, operational duality and effects ...................... 23 2.9 Delimited control ...................................... 24 2.10 Tensorial proof-nets and combinatorics of proofs .................... 24 2.11 Resource control in higher order languages ........................ 25 2.12 Resources in differential
    [Show full text]
  • An Optimizing Compiler for a Purely Functional Web-Application Language
    An Optimizing Compiler for a Purely Functional Web-Application Language Adam Chlipala MIT CSAIL, USA [email protected] Abstract conclude, then, that most Web applications would be written in C High-level scripting languages have become tremendously popular or other low-level languages that tend to enable the highest perfor- for development of dynamic Web applications. Many programmers mance. However, real-world programmers seem overwhelmingly to appreciate the productivity benefits of automatic storage manage- prefer the greater programming simplicity of high-level languages, ment, freedom from verbose type annotations, and so on. While it be they dynamically typed scripting languages like JavaScript or is often possible to improve performance substantially by rewrit- statically typed old favorites like Java. There is a genuine trade-off ing an application in C or a similar language, very few program- to be made between hardware costs for running a service and labor mers bother to do so, because of the consequences for human de- costs for implementing it. velopment effort. This paper describes a compiler that makes it Might there be a way to provide C-like performance for pro- possible to have most of the best of both worlds, coding Web ap- grams coded in high-level languages? While the concept of domain- plications in a high-level language but compiling to native code specific languages is growing in visibility, most Web applications with performance comparable to handwritten C code. The source are still written in general-purpose languages, coupled with Web- language is Ur/Web, a domain-specific, purely functional, stati- specific framework libraries.
    [Show full text]
  • Lisp: Final Thoughts
    20 Lisp: Final Thoughts Both Lisp and Prolog are based on formal mathematical models of computation: Prolog on logic and theorem proving, Lisp on the theory of recursive functions. This sets these languages apart from more traditional languages whose architecture is just an abstraction across the architecture of the underlying computing (von Neumann) hardware. By deriving their syntax and semantics from mathematical notations, Lisp and Prolog inherit both expressive power and clarity. Although Prolog, the newer of the two languages, has remained close to its theoretical roots, Lisp has been extended until it is no longer a purely functional programming language. The primary culprit for this diaspora was the Lisp community itself. The pure lisp core of the language is primarily an assembly language for building more complex data structures and search algorithms. Thus it was natural that each group of researchers or developers would “assemble” the Lisp environment that best suited their needs. After several decades of this the various dialects of Lisp were basically incompatible. The 1980s saw the desire to replace these multiple dialects with a core Common Lisp, which also included an object system, CLOS. Common Lisp is the Lisp language used in Part III. But the primary power of Lisp is the fact, as pointed out many times in Part III, that the data and commands of this language have a uniform structure. This supports the building of what we call meta-interpreters, or similarly, the use of meta-linguistic abstraction. This, simply put, is the ability of the program designer to build interpreters within Lisp (or Prolog) to interpret other suitably designed structures in the language.
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • How to Run Your Favorite Language in Web Browsers∗
    How to Run your Favorite Language in Web Browsers∗ The Revenge of Virtual Machines (over JavaScript) Benjamin Canou Emmanuel Chailloux LIP6 - UMR 7606 LIP6 - UMR 7606 Université Pierre et Marie Curie Université Pierre et Marie Curie Sorbonne Universités Sorbonne Universités 4 place Jussieu 4 place Jussieu 75005 Paris, France 75005 Paris, France [email protected] [email protected] Jérôme Vouillon CNRS, PPS UMR 7126 Univ Paris Diderot Sorbonne Paris Cité F-75205 Paris, France [email protected] ABSTRACT currency model or type system (to obtain a higher level of This paper is a concise guide for developers who want to expressivity or safety). port an existing language to Web browsers, about what to do and what not to. It is based on the various experiments However, the only common denominator between browsers that have been led in the OCaml language community. In in terms of programming capabilities is JavaScript. Plug-ins particular, it exhibits how reusing the underlying virtual used to be the way, but they are not available everywhere machine and bytecode associated to the language can come anymore. This means, on one hand, that there is no stan- of great help in this task. dard way to execute a program written in another language, and, on the other hand, that it has to be done through Categories and Subject Descriptors JavaScript. D.3.4 [Programming languages]: Processors We, the authors of this article, come from the OCaml[13] language community, in which several experiments have been General Terms led during the past few years to program the client part of Design, Languages, Experimentation Web applications.
    [Show full text]
  • 1. with Examples of Different Programming Languages Show How Programming Languages Are Organized Along the Given Rubrics: I
    AGBOOLA ABIOLA CSC302 17/SCI01/007 COMPUTER SCIENCE ASSIGNMENT ​ 1. With examples of different programming languages show how programming languages are organized along the given rubrics: i. Unstructured, structured, modular, object oriented, aspect oriented, activity oriented and event oriented programming requirement. ii. Based on domain requirements. iii. Based on requirements i and ii above. 2. Give brief preview of the evolution of programming languages in a chronological order. 3. Vividly distinguish between modular programming paradigm and object oriented programming paradigm. Answer 1i). UNSTRUCTURED LANGUAGE DEVELOPER DATE Assembly Language 1949 FORTRAN John Backus 1957 COBOL CODASYL, ANSI, ISO 1959 JOSS Cliff Shaw, RAND 1963 BASIC John G. Kemeny, Thomas E. Kurtz 1964 TELCOMP BBN 1965 MUMPS Neil Pappalardo 1966 FOCAL Richard Merrill, DEC 1968 STRUCTURED LANGUAGE DEVELOPER DATE ALGOL 58 Friedrich L. Bauer, and co. 1958 ALGOL 60 Backus, Bauer and co. 1960 ABC CWI 1980 Ada United States Department of Defence 1980 Accent R NIS 1980 Action! Optimized Systems Software 1983 Alef Phil Winterbottom 1992 DASL Sun Micro-systems Laboratories 1999-2003 MODULAR LANGUAGE DEVELOPER DATE ALGOL W Niklaus Wirth, Tony Hoare 1966 APL Larry Breed, Dick Lathwell and co. 1966 ALGOL 68 A. Van Wijngaarden and co. 1968 AMOS BASIC FranÇois Lionet anConstantin Stiropoulos 1990 Alice ML Saarland University 2000 Agda Ulf Norell;Catarina coquand(1.0) 2007 Arc Paul Graham, Robert Morris and co. 2008 Bosque Mark Marron 2019 OBJECT-ORIENTED LANGUAGE DEVELOPER DATE C* Thinking Machine 1987 Actor Charles Duff 1988 Aldor Thomas J. Watson Research Center 1990 Amiga E Wouter van Oortmerssen 1993 Action Script Macromedia 1998 BeanShell JCP 1999 AngelScript Andreas Jönsson 2003 Boo Rodrigo B.
    [Show full text]
  • Ocaml-Flat on the Ocsigen Framework
    Rita Pedroso Macedo Bachelor in Computer Science and Engineering OCaml-Flat on the Ocsigen framework Dissertation submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science and Engineering Adviser: Artur Miguel Dias, Auxiliar Professor, NOVA School of Science and Technology Co-adviser: António Ravara, Associate Professor, NOVA School of Science and Technology Examination Committee Chair: Doutor Jorge Cruz, FCT-NOVA Rapporteur: Doutora Nelma Moreira, FCUP Member: Doutor Artur Miguel Dias, FCT-NOVA August, 2020 OCaml-Flat on the Ocsigen framework Copyright © Rita Pedroso Macedo, NOVA School of Science and Technology, NOVA Uni- versity Lisbon. The NOVA School of Science and Technology and the NOVA University Lisbon have the right, perpetual and without geographical boundaries, to file and publish this dissertation through printed copies reproduced on paper or on digital form, or by any other means known or that may be invented, and to disseminate through scientific repositories and admit its copying and distribution for non-commercial, educational or research purposes, as long as credit is given to the author and editor. This document was created using the (pdf)LATEX processor, based on the “novathesis” template[1], developed at the Dep. Informática of FCT-NOVA [2]. [1] https://github.com/joaomlourenco/novathesis [2] http://www.di.fct.unl.pt Acknowledgements First and foremost, I would like to express my gratitude to the Tezos Foundation which grant supported the development of my project. My utmost appreciation goes to my Advisers, Professors Artur Miguel Dias and An- tónio Ravara, whose commitment and support throughout the development of this project have been relentless and inspirational.
    [Show full text]
  • Haskell-Like S-Expression-Based Language Designed for an IDE
    Department of Computing Imperial College London MEng Individual Project Haskell-Like S-Expression-Based Language Designed for an IDE Author: Supervisor: Michal Srb Prof. Susan Eisenbach June 2015 Abstract The state of the programmers’ toolbox is abysmal. Although substantial effort is put into the development of powerful integrated development environments (IDEs), their features often lack capabilities desired by programmers and target primarily classical object oriented languages. This report documents the results of designing a modern programming language with its IDE in mind. We introduce a new statically typed functional language with strong metaprogramming capabilities, targeting JavaScript, the most popular runtime of today; and its accompanying browser-based IDE. We demonstrate the advantages resulting from designing both the language and its IDE at the same time and evaluate the resulting environment by employing it to solve a variety of nontrivial programming tasks. Our results demonstrate that programmers can greatly benefit from the combined application of modern approaches to programming tools. I would like to express my sincere gratitude to Susan, Sophia and Tristan for their invaluable feedback on this project, my family, my parents Michal and Jana and my grandmothers Hana and Jaroslava for supporting me throughout my studies, and to all my friends, especially to Harry whom I met at the interview day and seem to not be able to get rid of ever since. ii Contents Abstract i Contents iii 1 Introduction 1 1.1 Objectives ........................................ 2 1.2 Challenges ........................................ 3 1.3 Contributions ...................................... 4 2 State of the Art 6 2.1 Languages ........................................ 6 2.1.1 Haskell ....................................
    [Show full text]
  • Programming Language Use in US Academia and Industry
    Informatics in Education, 2015, Vol. 14, No. 2, 143–160 143 © 2015 Vilnius University DOI: 10.15388/infedu.2015.09 Programming Language Use in US Academia and Industry Latifa BEN ARFA RABAI1, Barry COHEN2, Ali MILI2 1 Institut Superieur de Gestion, Bardo, 2000, Tunisia 2 CCS, NJIT, Newark NJ 07102-1982 USA e-mail: [email protected], [email protected], [email protected] Received: July 2014 Abstract. In the same way that natural languages influence and shape the way we think, program- ming languages have a profound impact on the way a programmer analyzes a problem and formu- lates its solution in the form of a program. To the extent that a first programming course is likely to determine the student’s approach to program design, program analysis, and programming meth- odology, the choice of the programming language used in the first programming course is likely to be very important. In this paper, we report on a recent survey we conducted on programming language use in US academic institutions, and discuss the significance of our data by comparison with programming language use in industry. Keywords: programming language use, academic institution, academic trends, programming lan- guage evolution, programming language adoption. 1. Introduction: Programming Language Adoption The process by which organizations and individuals adopt technology trends is complex, as it involves many diverse factors; it is also paradoxical and counter-intuitive, hence difficult to model (Clements, 2006; Warren, 2006; John C, 2006; Leo and Rabkin, 2013; Geoffrey, 2002; Geoffrey, 2002a; Yi, Li and Mili, 2007; Stephen, 2006). This general observation applies to programming languages in particular, where many carefully de- signed languages that have superior technical attributes fail to be widely adopted, while languages that start with modest ambitions and limited scope go on to be widely used in industry and in academia.
    [Show full text]
  • Categorical Variable Consolidation Tables
    CATEGORICAL VARIABLE CONSOLIDATION TABLES FlossMole Data Name Old number of codes New number of codes Table 1: Intended Audience 19 5 Table 2: FOSS Licenses 60 7 Table 3: Operating Systems 59 8 Table 4: Programming languages 73 8 Table 5: SF Project topics 243 19 Table 6: Project user interfaces 48 9 Table 7 DB Environment 33 3 Totals 535 59 Table 1: Intended Audience: Consolidated from 19 to 4 categories Rationale for this consolidation: Categories that had similar characteristics were grouped together. For example, Customer Service, Financial and Insurance, Healthcare Industry, Legal Industry, Manufacturing, Telecommunications Industry, Quality Engineers and Aerospace were grouped together under the new category “Business.” End Users/Desktop and Advanced End Users were grouped together under the new category “End Users.” Developers, Information Technology and System Administrators were grouped together under the new category “Computer Professionals.” Education, Religion, Science/Research and Other Audience were grouped under the new category “Other.” Categories containing large numbers of projects were generally left as individual categories. Perhaps Religion and Education should have be left as separate categories because of they contain a relatively large number of projects. Since Mike recommended we get the number of categories down to 50, I consolidated them into the “Other” category. What was done: I created a new table in sf merged called ‘categ_intend_aud_aug06’. This table is a duplicate of the ‘project_intended_audience01_aug_06’ table with the fields ‘new_code’ and ‘new_description’ added. I updated the new fields in the new table with the new codes and descriptions listed in the table below using a python script I (Bob English) wrote called add_categ_intend_aud.py.
    [Show full text]
  • From Krivine's Machine to the Caml Implementations
    From Krivine's machine to the Caml implementations Xavier Leroy INRIA Rocquencourt 1 In this talk An illustration of the strengths and limitations of abstract machines for the purpose of e±cient execution of strict functional languages (Caml). 1. A retrospective on the ZAM, a call-by-value variant of Krivine's machine. 2. From abstract machines to e±cient P.L. implementations: the example of Caml Light and Objective Caml. 3. Beyond abstract machines: push-enter models vs. eval-apply models. 2 Why are abstract machines interesting? On the theory side (λ-calculus, semantics): Abstract machines expose concepts lacking or implicit in the λ-calculus: • Reduction strategy, evaluation order. • Data representations, esp. closures and environments. On the implementation side: Compilation to abstract machine code o®ers much better performance than interpreters. Abstract machine code as an intermediate language for machine-code generation. Abstract machine code as an architecture-independent low-level format for distributing compiled programs (JVM, .Net). 3 There are better ways In every area where abstract machines help, there are arguably better alternatives: • Exposing reduction order: CPS transformation, structured operational semantics, reduction contexts. • Closures and environments: explicit substitutions. • E±cient execution: optimizing compilation to real machine code. • Intermediate languages: RTL, SSA, CPS, A-normal forms, etc. • Code distribution: ANDF (?). Abstract machines do many things well but none very well. This we will illustrate in the case of e±cient execution of Caml. 4 A retrospective on the ZAM 5 The starting point The Caml language and implementation circa 1989: • Core ML (CBV λ-calculus) with primitives, data types and pattern-matching.
    [Show full text]
  • Ur/Web: a Simple Model for Programming the Web
    Ur/Web: A Simple Model for Programming the Web The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Chlipala, Adam. "Ur/Web: A Simple Model for Programming the Web." The 42nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL '15), January 15-17, 2015, Mumbai, India. As Published http://dl.acm.org/citation.cfm?id=2676726 Publisher Association for Computing Machinery (ACM) Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/92321 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ Ur/Web: A Simple Model for Programming the Web Adam Chlipala rtifact Comple * A t * te n * te A is W s E * e n l l C o L D MIT CSAIL C o P * * c u e m s O E u e e P n R t v e [email protected] o d t * y * s E a a l d u e a t Abstract for network communication, and on a language or API like SQL The World Wide Web has evolved gradually from a document de- for storing persistent, structured data on servers. Code fragments livery platform to an architecture for distributed programming. This in these different languages are often embedded within each other largely unplanned evolution is apparent in the set of interconnected in complex ways, and the popular Web development tools provide languages and protocols that any Web application must manage. little help in catching inconsistencies.
    [Show full text]