DOCSLIB.ORG

From JSON to JSEN Through Virtual Languages of the Creative Commons Attribution License (

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
From JSON to JSEN Through Virtual Languages of the Creative Commons Attribution License ( © 2021 by the authors; licensee RonPub, Lübeck, Germany. This article is an open access article distributed under the terms and conditions A.of Ceravola, the Creative F. Joublin:Commons From Attribution JSON to license JSEN through(http://c reativecommons.org/licenses/by/4Virtual Languages .0/). Open Access Open Journal of Web Technology (OJWT) Volume 8, Issue 1, 2021 www.ronpub.com/ojwt ISSN 2199-188X From JSON to JSEN through Virtual Languages Antonello Ceravola, Frank Joublin Honda Research Institute Europe GmbH, Carl Legien Str. 30, Offenbach/Main, Germany, {Antonello.Ceravola, Frank.Joublin}@honda-ri.de ABSTRACT In this paper we describe a data format suitable for storing and manipulating executable language statements that can be used for exchanging/storing programs, executing them concurrently and extending homoiconicity of the hosting language. We call it JSEN, JavaScript Executable Notation, which represents the counterpart of JSON, JavaScript Object Notation. JSON and JSEN complement each other. The former is a data format for storing and representing objects and data, while the latter has been created for exchanging/storing/executing and manipulating statements of programs. The two formats, JSON and JSEN, share some common properties, reviewed in this paper with a more extensive analysis on what the JSEN data format can provide. JSEN extends homoiconicity of the hosting language (in our case JavaScript), giving the possibility to manipulate programs in a finer grain manner than what is currently possible. This property makes definition of virtual languages (or DSL) simple and straightforward. Moreover, JSEN provides a base for implementing a type of concurrent multitasking for a single-threaded language like JavaScript. TYPE OF PAPER AND KEYWORDS Regular Research Paper: JSEN, JSON, executable data structures, homoiconic languages, metaprogramming, virtual languages, concurrency, threading 1 INTRODUCTION astronomy, and several others. However, along its wide usage, XML has been criticized for its verbosity and There is a large variety of data formats available for complexity [33][35], consequently giving space for storing or transferring information between different other data formats to emerge [34]. One of the most software systems. Some of them are focused on used alternatives is JSON [15][16]. Considered lighter, specific domains while others are general purpose and simpler, and more readable than XML [27][37]; JSON can be easily used cross-domain. In this second group, belongs to the family of general-purpose data formats, XML is one of the most well-known data formats, and continues gaining space in new domains, designed in 1996 by the XML Working Group [7] [36] particularly among Internet applications. with the target of being a general-purpose data format, We use JSON data structures for storing and easy to read and usable on Internet applications. XML transmitting data across different subsystems in one of received a lot of attention from different communities our projects, a web-based, client-server avatar system. [33] leading to its usage in domains such as It is implemented with HTML, CSS and JavaScript, government, chemistry, telecommunication, used in both client and server side [32]. For some 1 Open Journal of Web Technology (OJWT), Volume 8, Issue 1, 2021 specific functionalities we came across the requirement manage asynchronous code as well as the need to of storing and manipulating code programmatically, in easily implement concurrent processing particularly ways not possible with JavaScript. We had to important in artificial intelligence systems. On the way programmatically control function’s execution, in some to the proposed solution, we discovered that object cases we had to execute functions in a concurrent way, oriented and functional programming provided by as well as injecting or removing code statements on JavaScript was not sufficient for the problem we were them. This type of code manipulation is supported by tackling and therefore we needed language extensions homoiconic languages: “In a homoiconic language, the which were not easily possible in JavaScript. For primary representation of programs is also a data example, our applications had the needs to model event structure in a primitive type of the language itself” based concurrent programs which, through JSEN [4][25]. became easily implementable. JavaScript provides a degree of homoiconicity [6] In the next paragraph we are going to describe the allowing introspection of classes, prototypes, and structure of this paper, touching the different concepts members. It allows dynamic changes like adding/ that will be elaborated in the different sections. removing or redefining members in classes/objects. JavaScript gives access to functions, by allowing 1.2 OVERVIEW access to their names, parameters, or their full source code (as a single string by applying the method In this paper we start the introduction of JSEN, in the “.toString()” to a function identifier). However, paragraph 2, by first looking at JSON. The two data JavaScript homoiconicity do not go beyond this; for formats are similar and complementary. This is an instance, it is not possible to have access to function’s important relation that facilitate the introduction of this individual statements or parts of them. A greater level work. In the paragraph 2.2, by describing JSEN, we of introspection/manipulation, instead, can be found in introduce its core principles on which it is based: homoiconic languages like Lisp [31], SmallTalk [11] or closure and heterogenous multi-dimensional arrays. At Tcl [28] and in the JavaScript macro language of that stage we explain the syntax, we describe how Majaho [14], as well as EsLisp [19]. In particular, the JSEN extends JavaScript homoiconicity, we introduce latter implements a Lisp based e-expression syntax for the concept of JSEN virtual machine and virtual JavaScript, where programs are natively stored in data languages. In the paragraph 2.3 we show how to go structures fully accessible in a programmatic way by from the definition of a JSEN data structure to its programs themselves. execution. Looking at JSEN as a storage format, in the In this paper, we describe a data structure that paragraph 2.4 we show how, similarly as JSON, JSEN allows a finer degree of access to function statements. can be used to transfer programs across systems. We called this format JSEN, JavaScript Executable We then describe, in the paragraph 3, the Notation (name inspired by the symmetric relations architecture of JSEN, to understand how JSEN can be between JSEN and JSON). Where JSON is a data used in applications. The paragraph 3.1, goes deeper format for storing and manipulating objects (data), into virtual languages, introducing how JSEN data JSEN is a format for storing and manipulating structures can be executed. In the paragraph 3.2 we executable code. Furthermore, with JSEN we can then investigate more details on the memory easily handle asynchronous functions without falling representation of JSEN by stepping into the stages of into the callback-hell pattern. In this paper, we describe JSEN definition, compilation, and execution. Existing the JSEN format, giving a glimpse on some of the concurrent/asynchronous methods available in interesting features we could derive from that. JSEN is JavaScript are then compared with JSEN in the available as Open-Source Software in GitHub at paragraph 3.3. The paragraph 3.4 describes in more https://github.com/HRI-EU/JSEN. All necessary details how a JSEN virtual machine works and how it libraries are present, with examples and all source can execute JSEN data structures in a concurrent way. snippet mentioned in this paper. We will now draw the We complete our analysis in the paragraph 4 by reasons that led us to introduce JSEN before we give an showing the main properties of JSEN like extended overview of the structure of the paper. homoiconicity for the hosting language, introduction of code serialization, execution performance of JSEN vs 1.1 MOTIVATION native code, virtual language support/extension and execution of concurrent code. We close the paper with Our experience with JavaScript has put in light several the paragraph 5 by shortly describing what has been limitations that JSEN is trying to overcome. The intentionally left out from this paper, which will then starting point for us has been the needs to be addressed in follow up papers, and we give a programmatically control function’s execution, to 2 A. Ceravola, F. Joublin: From JSON to JSEN through Virtual Languages summary and conclusions in the paragraph 6. Let us exchange/storing format. Elements of JSEN can be start now with the origin of the name. anonymous functions, pure JSEN statements, strings, arrays and objects. In Listing 2 we show an example of 2 FROM JSON TO JSEN a JSEN data structure for a program that implements the computation of prime numbers. For a more gradual introduction we show here how The choice of using arrays as supporting structure JSEN can be easily understood by looking at its for JSEN, comes from the needs of representing relations with JSON. sequences of statements of a program: arrays elements are ordered and can represent a sequence. Programs are 2.1 JSON also constituted of blocks and sub-blocks; similarly, arrays in JavaScript can be nested. In this way, it is JSON is a human readable data format based on the possible, in JSEN, to express any algorithm with JavaScript language, shaped around the syntax of arbitrary nesting and complexity. JavaScript object literals [18]. It has been defined with Let us look at JSEN from a closer perspective. The the purpose of encapsulating data that could be used or example (1) in Listing 3 shows an empty JSEN data manipulated in a program as well as used as data structure (empty array): empty program. The example exchange/storage format. The elements of a JSON data (2) in Listing 3 shows how to specify a comment.
Load more

Recommended publications
  • A Concurrent PASCAL Compiler for Minicomputers
    512 Appendix A DIFFERENCES BETWEEN UCSD'S PASCAL AND STANDARD PASCAL The PASCAL language used in this book contains most of the features described by K. Jensen and N. Wirth in PASCAL User Manual and Report, Springer Verlag, 1975. We refer to the PASCAL defined by Jensen and Wirth as "Standard" PASCAL, because of its widespread acceptance even though no international standard for the language has yet been established. The PASCAL used in this book has been implemented at University of California San Diego (UCSD) in a complete software system for use on a variety of small stand-alone microcomputers. This will be referred to as "UCSD PASCAL", which differs from the standard by a small number of omissions, a very small number of alterations, and several extensions. This appendix provides a very brief summary Of these differences. Only the PASCAL constructs used within this book will be mentioned herein. Documents are available from the author's group at UCSD describing UCSD PASCAL in detail. 1. CASE Statements Jensen & Wirth state that if there is no label equal to the value of the case statement selector, then the result of the case statement is undefined. UCSD PASCAL treats this situation by leaving the case statement normally with no action being taken. 2. Comments In UCSD PASCAL, a comment appears between the delimiting symbols "(*" and "*)". If the opening delimiter is followed immediately by a dollar sign, as in "(*$", then the remainder of the comment is treated as a directive to the compiler. The only compiler directive mentioned in this book is (*$G+*), which tells the compiler to allow the use of GOTO statements.
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Open Office Specification 1.0
    Open Office Specification 1.0 Committee Draft 1, 22 Mar 2004 Document identifier: office-spec-1.0-cd-1.sxw Location: http://www.oasis-open.org/committees/office/ Editors: Michael Brauer, Sun Microsystems <[email protected]> Gary Edwards <[email protected]> Daniel Vogelheim, Sun Microsystems <[email protected]> Contributors: Doug Alberg, Boeing <[email protected]> Simon Davis, National Archive of Australia <[email protected]> Patrick Durusau, Society of Biblical Literature <[email protected]> David Faure, <[email protected]> Paul Grosso, Arbortext <[email protected]> Tom Magliery, Blast Radius <[email protected]> Phil Boutros, Stellent <[email protected]> John Chelsom, CSW Informatics <[email protected]> Jason Harrop, SpeedLegal <[email protected]> Mark Heller, New York State Office of the Attorney General <[email protected]> Paul Langille, Corel <[email protected]> Monica Martin, Drake Certivo <[email protected]> Uche Ogbuji <[email protected]> Lauren Wood <[email protected]> Abstract: This is the specification of Open Office XML, an open, XML-based file format for office applications, based on OpenOffice.org XML [OOo]. Status: This document is a draft, and will be updated periodically on no particular schedule. Send comments to the editors. Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to office- [email protected] with the word "subscribe" as the body of the message.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems
    The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems Neelakantan R. Krishnaswami University of Birmingham <[email protected]> 1. Introduction body of a macro definition do not interfere with names oc- Typically, when semanticists hear the words “Scheme” or curring in the macro’s arguments. Consider this definition of and “Lisp”, what comes to mind is “untyped lambda calculus a short-circuiting operator: plus higher-order state and first-class control”. Given our (define-syntax and typical concerns, this seems to be the essence of Scheme: it (syntax-rules () is a dynamically typed applied lambda calculus that sup- ((and e1 e2) (let ((tmp e1)) ports mutable data and exposes first-class continuations to (if tmp the programmer. These features expose a complete com- e2 putational substrate to programmers so elegant that it can tmp))))) even be characterized mathematically; every monadically- representable effect can be implemented with state and first- In this definition, even if the variable tmp occurs freely class control [4]. in e2, it will not be in the scope of the variable definition However, these days even mundane languages like Java in the body of the and macro. As a result, it is important to support higher-order functions and state. So from the point interpret the body of the macro not merely as a piece of raw of view of a working programmer, the most distinctive fea- syntax, but as an alpha-equivalence class. ture of Scheme is something quite different – its support for 2.2 Open Recursion macros. The intuitive explanation is that a macro is a way of defining rewrites on abstract syntax trees.
    [Show full text]
  • Star TEX: the Next Generation Several Ideas on How to Modernize TEX Already Exist
    TUGboat, Volume 33 (2012), No. 2 199 Star TEX: The Next Generation Several ideas on how to modernize TEX already exist. Some of them have actually been implemented. Didier Verna In this paper, we present ours. The possible future Abstract that we would like to see happening for TEX is some- what different from the current direction(s) TEX's While T X is unanimously praised for its typesetting E evolution has been following. In our view, modern- capabilities, it is also regularly blamed for its poor izing TEX can start with grounding it in an old yet programmatic offerings. A macro-expansion system very modern programming language: Common Lisp. is indeed far from the best choice in terms of general- Section 2 clarifies what our notion of a \better", or purpose programming. Several solutions have been \more modern" TEX is. Section 3 on the next page proposed to modernize T X on the programming E presents several approaches sharing a similar goal. side. All of them currently involve a heterogeneous Section 4 on the following page justifies the choice approach in which T X is mixed with a full-blown pro- E of Common Lisp. Finally, section 5 on page 205 gramming language. This paper advocates another, outlines the projected final shape of the project. homogeneous approach in which TEX is first rewrit- ten in a modern language, Common Lisp, which 2 A better TEX serves both at the core of the program and at the The T X community has this particularity of being scripting level. All programmatic macros of T X are E E a mix of two populations: people coming from the hence rendered obsolete, as the underlying language world of typography, who love it for its beautiful itself can be used for user-level programming.
    [Show full text]
  • Functional Programming Patterns in Scala and Clojure Write Lean Programs for the JVM
    Early Praise for Functional Programming Patterns This book is an absolute gem and should be required reading for anybody looking to transition from OO to FP. It is an extremely well-built safety rope for those crossing the bridge between two very different worlds. Consider this mandatory reading. ➤ Colin Yates, technical team leader at QFI Consulting, LLP This book sticks to the meat and potatoes of what functional programming can do for the object-oriented JVM programmer. The functional patterns are sectioned in the back of the book separate from the functional replacements of the object-oriented patterns, making the book handy reference material. As a Scala programmer, I even picked up some new tricks along the read. ➤ Justin James, developer with Full Stack Apps This book is good for those who have dabbled a bit in Clojure or Scala but are not really comfortable with it; the ideal audience is seasoned OO programmers looking to adopt a functional style, as it gives those programmers a guide for transitioning away from the patterns they are comfortable with. ➤ Rod Hilton, Java developer and PhD candidate at the University of Colorado Functional Programming Patterns in Scala and Clojure Write Lean Programs for the JVM Michael Bevilacqua-Linn The Pragmatic Bookshelf Dallas, Texas • Raleigh, North Carolina Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals.
    [Show full text]
  • Lisp, Jazz, Aikido Three Expressions of a Single Essence
    Lisp, Jazz, Aikido Three Expressions of a Single Essence Didier Vernaa a EPITA Research and Development Laboratory Abstract The relation between Science (what we can explain) and Art (what we can’t) has long been acknowledged and while every science contains an artistic part, every art form also needs a bit of science. Among all scientific disciplines, programming holds a special place for two reasons. First, the artistic part is not only undeniable but also essential. Second, and much like in a purely artistic discipline, the act of programming is driven partly by the notion of aesthetics: the pleasure we have in creating beautiful things. Even though the importance of aesthetics in the act of programming is now unquestioned, more could still be written on the subject. The field called “psychology of programming” focuses on the cognitive aspects ofthe activity, with the goal of improving the productivity of programmers. While many scientists have emphasized their concern for aesthetics and the impact it has on their activity, few computer scientists have actually written about their thought process while programming. What makes us like or dislike such and such language or paradigm? Why do we shape our programs the way we do? By answering these questions from the angle of aesthetics, we may be able to shed some new light on the art of programming. Starting from the assumption that aesthetics is an inherently transversal dimension, it should be possible for every programmer to find the same aesthetic driving force in every creative activity they undertake, not just programming, and in doing so, get deeper insight on why and how they do things the way they do.
    [Show full text]
  • Lisp, Jazz, Aikido – Three Expressions of a Single Essence Didier Verna
    Lisp, Jazz, Aikido – Three Expressions of a Single Essence Didier Verna To cite this version: Didier Verna. Lisp, Jazz, Aikido – Three Expressions of a Single Essence. The Art, Science, and Engineering of Programming, aosa, Inc., 2018, 2 (3), 10.22152/programming-journal.org/2018/2/10. hal-01813470 HAL Id: hal-01813470 https://hal.archives-ouvertes.fr/hal-01813470 Submitted on 12 Jun 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Lisp, Jazz, Aikido Three Expressions of a Single Essence Didier Vernaa a EPITA Research and Development Laboratory Abstract The relation between Science (what we can explain) and Art (what we can’t) has long been acknowledged and while every science contains an artistic part, every art form also needs a bit of science. Among all scientific disciplines, programming holds a special place for two reasons. First, the artistic part is not only undeniable but also essential. Second, and much like in a purely artistic discipline, the act of programming is driven partly by the notion of aesthetics: the pleasure we have in creating beautiful things. Even though the importance of aesthetics in the act of programming is now unquestioned, more could still be written on the subject.
    [Show full text]
  • Basic Lisp Techniques
    Basic Lisp Techniques David J. Cooper, Jr. February 14, 2011 ii 0Copyright c 2011, Franz Inc. and David J. Cooper, Jr. Foreword1 Computers, and the software applications that power them, permeate every facet of our daily lives. From groceries to airline reservations to dental appointments, our reliance on technology is all-encompassing. And, it’s not enough. Every day, our expectations of technology and software increase: • smart appliances that can be controlled via the internet • better search engines that generate information we actually want • voice-activated laptops • cars that know exactly where to go The list is endless. Unfortunately, there is not an endless supply of programmers and developers to satisfy our insatiable appetites for new features and gadgets. Every day, hundreds of magazine and on-line articles focus on the time and people resources needed to support future technological expectations. Further, the days of unlimited funding are over. Investors want to see results, fast. Common Lisp (CL) is one of the few languages and development options that can meet these challenges. Powerful, flexible, changeable on the fly — increasingly, CL is playing a leading role in areas with complex problem-solving demands. Engineers in the fields of bioinformatics, scheduling, data mining, document management, B2B, and E-commerce have all turned to CL to complete their applications on time and within budget. CL, however, no longer just appropriate for the most complex problems. Applications of modest complexity, but with demanding needs for fast development cycles and customization, are also ideal candidates for CL. Other languages have tried to mimic CL, with limited success.
    [Show full text]
  • Nesting Forward-Mode AD in a Functional Framework Jeffrey M
    Purdue University Purdue e-Pubs ECE Technical Reports Electrical and Computer Engineering 1-1-2008 Nesting Forward-Mode AD in a Functional Framework Jeffrey M. Siskind Purdue University, [email protected] Barak A. Pearlmutter NUI Maynooth Co. Kildare, [email protected] Follow this and additional works at: http://docs.lib.purdue.edu/ecetr Part of the Electrical and Computer Engineering Commons Siskind, Jeffrey M. and Pearlmutter, Barak A., "Nesting Forward-Mode AD in a Functional Framework" (2008). ECE Technical Reports. Paper 377. http://docs.lib.purdue.edu/ecetr/377 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. Purdue ECE TR-08-09 Nesting Forward-Mode AD in a Functional Framework Jeffrey Mark Siskind School of Electrical & Computer Engineering Purdue University 465 Northwestern Avenue West Lafayette, IN 47907-2035 USA +1 765 496 3197 [email protected] Barak A. Pearlmutter Hamilton Institute NUI Maynooth Co. Kildare Ireland +353 1 708 6100 [email protected] Abstract We discuss the augmentation of a functional-programming language with a derivative- taking operator implemented with forward-mode automatic differentiation (AD). The primary technical difficulty in doing so lies in ensuring correctness in the face of nested invocation of that operator, due to the need to distinguish perturbations introduced by distinct invocations. We exhibit a series of implementations of a referentially- transparent forward-mode-AD derivative-taking operator, each of which uses a different non-referentially-transparent mechanism to distinguish perturbations. Even though the forward-mode-AD derivative-taking operator is itself referentially transparent, we hypothesize that one cannot correctly formulate this operator as a function definition in current pure dialects of Haskell.
    [Show full text]
  • SMC2011 Template
    From Live Coding to Virtual Being Nikolai Suslov Tatiana Soshenina Fund for Supporting Moscow Institute of Architecture Development of Russian Technology State Academy! Vologda, Russia Moscow, Russia [email protected] [email protected] ABSTRACT "e self#explorative, colla%orative environments and virtual worlds are se&ing up the new standards in so'ware engineering for today( In this, live coding is also re)uired in reviewing as for programmers and as for artists too( "e most popular live coding frameworks, even %eing %uilt %y using highly dynamic, re+ective languages, still suffer on tight %indings to single#node or client#server architecture, language or platform dependence and third#party tools. "at leads to ina%ility nor to develop nor scale to the Internet of things the new created works using live coding. In the paper we introduce the prototype of integration of o%ject#oriented language for pa&ern matching .Meta onto Virtual /orld Framework on 0avaScript( "at integration will allow using the live coding in virtual worlds with user-de1ned languages. Also we explore the possi%ilities of a conformal scaling of live coding in the case of augmented reality systems and Internet of things. In summary, the paper descri%es the efforts %eing done for involving virtual worlds architecture in live coding process. All prototypes that are descri%ed in the paper are availa%le for experimenting with on 2restianstvo SD2 open source project3 h&p344www(*restianstvo(org 1. FROM CO !R TOOLS TO S!LF E"#LORAT$VE% COLLABORAT$VE ENVIRONMENTS Fundamentally, live coding is a%out highly dynamic programming languages, re+ectivity, homoiconicity and Meta properties.
    [Show full text]