Proceedings of ILC 2014 on 8th International Lisp Conference最新文献

{"title":"PaGe: Portable LALR(1) Parser Generator","authors":"Suda Keishi, Abe Seika","doi":"10.1145/2635648.2635650","DOIUrl":"https://doi.org/10.1145/2635648.2635650","url":null,"abstract":"PaGe is a portable, compact and reliable LALR(1) parser generator with more general disambiguation method compared to that of traditional parser generator such as Bison. From the past to the present, very many parser generators are implemented in various programming languages. In particular, Bison in C language is a notable one due to its high efficiency and reliability. It is surely the de fact standard parser generator in C. We have recently faced with a requirement of making some parsers for relatively large languages in Common Lisp. We prefer commercial products due to its reliability and user supports. Especially, problems with such complex tool should only be solved by someone who has deep knowledge about the tool. Thus, we chose ACL (Allegro Common Lisp) which is one of the most widely used Lisp programming environment. Unfortunately, ACL does not provide official parser generator. As for free software, as far as we know, there is no such tool comparable to Bison in the above sense. Since Lisp has powerful and universal syntactic expression, namely S-expression, it is sufficient for Lispers to express and handle any syntactic objects. We suspect that that is why parser generators are not so important to Lispers. Nevertheless reliable parser generator in Lisp is needed when we develop tools dealing with anther languages, such as compilers and program analizers. This is the motivation for developing original parser generator in Lisp. One of PaGe's concept is to give a legible implementation of DeRemer's method for Look-Ahead Set. This method makes us enable to generate LALR(1)-parsing-table dircetly from LR(0)-parsing-table by computing Look-Ahead Set based on formal definitions of them. For example, DeRemer's method has used in Bison, but there is few other implementation, particularly on Lisp. Therefore we decided to give a legible implementation for who would like to understand it. Other concept is to simplify PaGe's core program for efficiency and readability as possible. As a result, PaGe is composed of parser generator engine PaGEn and its wrapper. PaGEn is a pared parser-generator engine. PaGEn's input is a grammar whose \"symbols\" are restricted to non-negative integer. By this restriction, we were able to establish both program efficiency and algorithm readablity, for instance we can naturally use array as function. Consequently, the role of wrapper are mainly two of translation and interpreting. A wrapper translates symbolic input such as grammar or sequence of token into numeric input for PaGEn. PaGEn get this as input and return parsing-table or result of parse, for instance. Then the wrapper interprets this result for an user or other system. Now, we have defined only the wrapper for using PaGEn in the same way for traditional parser generator. If you wish to use PaGEn for other purpose, you need only to define the wrapper. Furthermore, PaGEn can deal with ambiguous grammar i.e. it supports disambiguation. PaGEn's disambiguation ","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"48 5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117125882","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Resolving Metastability Issues During Bootstrapping","authors":"R. Strandh","doi":"10.1145/2635648.2635656","DOIUrl":"https://doi.org/10.1145/2635648.2635656","url":null,"abstract":"The fact that CLOS is defined as a CLOS program introduces two categories of issues that must be addressed, namely bootstrapping issues and metastability issues [2]. Of the two, the latter is the more difficult one, and also the one that has the most negative impact on the elegance of the code in that it requires base cases to be handled specially. We describe satiation, a technique by which metastability issues can be turned into bootstrapping issues, thereby simplifying them and keeping the code elegant. Satiation consists of pre-loading the call history of a generic function with respect to a set of argument classes so that the base cases are handled without invoking the full protocol for computing the effective methods at runtime.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130089369","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Multiplatform and Mobile App Development in Scheme with Gambit/SchemeSpheres","authors":"Álvaro Castro-Castilla","doi":"10.1145/2635648.2635659","DOIUrl":"https://doi.org/10.1145/2635648.2635659","url":null,"abstract":"This document explains the motivation and fundamental ideas behind the SchemeSpheres1 project. It outlines the conceptual approach taken by this framework, given a set of requirements that are considered essential. The different sides of the key aspects that SchemeSpheres tackles are summarized, focusing especially on the set of tools supporting multiplatform/mobile app development that it provides. Current implementation supports most of the required functionality, which will be explored along with the process of building an example app. Limitations of the framework will be discussed during the tutorial, exploring possible future solutions as well current workarounds.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"40 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132274398","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Reaching Python from Racket","authors":"P. Ramos, A. Leitão","doi":"10.1145/2635648.2635660","DOIUrl":"https://doi.org/10.1145/2635648.2635660","url":null,"abstract":"Racket is a descendant of Scheme, a language that has been widely used to teach computer science. Recently, the Python language has taken over this role, mainly due to its huge standard library and the great number of third-party libraries available. Given that the development of equivalent libraries for Racket is an enormous task that cannot be currently done in an acceptable time frame, the next best option is to allow the Racket platform to use Python programs and libraries. We have been developing an implementation of Python for the Racket platform based on a source-to-source compiler. In order to provide good performance and good interoperability with the Racket platform, the runtime libraries are being implemented over Racket data-types. This, however, entails implementing all of Python's standard library on Racket and it does not provide access to popular Python libraries implemented using C module extensions (such as Numpy and SciPy). This paper presents an alternative approach that allows libraries from Python's reference implementation to be imported and used in our Racket implementation of Python, immediately providing access to all of Python's standard library and every third-party library, including NumPy and SciPy. The proposed solution involves importing Python module objects directly from Python's virtual machine, by calling the Python/C API through Racket's Foreign Function Interface, and converting them to objects usable by our Racket runtime libraries, making them compatible with the Racket platform. This compatibility layer therefore relies on relatively expensive foreign function calls to Python's libraries, but our performance tests show that the overhead introduced by them is quite low and, for most cases, it can be minimized in order to attain the same performance as Python's reference implementation.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"144 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125772810","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"A Gentle Introduction to Gendl®, a Common Lisp-based Knowledge Based Engineering Environment","authors":"D. Cooper","doi":"10.1145/2635648.2635665","DOIUrl":"https://doi.org/10.1145/2635648.2635665","url":null,"abstract":"In this two-hour tutorial we will introduce the Gendl® project (source available at http://github.com/genworks/gendl), and we will cover the following topics: 1. Installation either through Quicklisp or though a pre-built install package 2. Basic Gendl® declarative authoring syntax 3. Example Non-geometric application 4. Example geometric application (twisty tower) 5. Example geometric application with a mechanism (4-bar link) 6. Adding a web user interface 7. Building a runtime application, including integrated web server, using ASDF3's new application delivery capabilities 8. Uploading and deploying the runtime application on a server","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132670927","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"A Scheme-Based Closed-Loop Anesthesia System","authors":"C. Petersen, M. Görges, J. Ansermino, G. Dumont","doi":"10.1145/2635648.2635651","DOIUrl":"https://doi.org/10.1145/2635648.2635651","url":null,"abstract":"Many aspects of modern medicine, including the administration of anesthetic agents during general surgery, remain unautomated and reliant on the vigilance of the attending clinicians. In other fields where failures can have catastrophic consequences, such as the aviation and nuclear power industry, automated control regimens have been adopted to reduce the risks and improve performance. In this paper we discuss many aspects of the implementation of a complete automated system for intravenous anesthetic drug infusion based on feedback from electroencephalography (EEG) readings. The system software in its entirety consists of approximately 22K lines of Scheme code and features a client-server implementation interfacing medical devices with a portable graphical user interface. The user interface runs on both mobile devices and dedicated medical flat panel displays. The strengths of the Scheme functional language have been leveraged to build a robust maintainable modular system with extensive testing facilities to mitigate the inherent safety hazards associated with the application.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"134 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123437450","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Efficient Finite Permutation Groups and Homomesy Computation in Common Lisp","authors":"Robert Smith, Brendan Pawlowski","doi":"10.1145/2635648.2635664","DOIUrl":"https://doi.org/10.1145/2635648.2635664","url":null,"abstract":"The study of permutations is of central importance to mathematics. Computation with permutation groups has typically been limited to systems such as GAP and Magma. In this paper we describe cl-permutation, a system for doing computations with permutation groups in ANSI Common Lisp. Homomesies, a recent concept introduced by Propp and Roby, are elaborated upon from a group-theoretic and linear-algebraic perspective. As a result, algorithms for manipulating them and better understanding their structure are presented. Finally, these algorithms are realized using cl-permutation.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128213574","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Kilns: A Lisp Without Lambda","authors":"Greg Pfeil","doi":"10.1145/2635648.2635663","DOIUrl":"https://doi.org/10.1145/2635648.2635663","url":null,"abstract":"Kilns is a programming language based on the kell calculus. The kell calculus can roughly be seen as an extension of the πCalculus that adds a notion of \"locality\" (the kell), which provides semi-permeable boundaries that make it possible to restrict the type of communication between components (E.G., machine-local, rather than network). This kell construct also allows for very direct encodings of things like data encapsulation and security capabilities. Kilns has several unique features. While lambdas have been implemented as a library, they are not part of the core language. It also has modified versions of other features that are often considered fundamental to being a lisp. Some examples: Macros are \"lazy\" -- calls to macros can exist before the macro is visible in the relevant scope, and macros are only expanded when the calls exist in certain syntactic contexts (this allows embedding macro calls in mobile processes that will be expanded in some other environment). The fundamental data (and code) structure is not a list, but a multimap. These distinctions have largely come about while finding natural ways to embed the original lispisms in the kell calculus. In trying to minimize the size of the core language while making performance acceptable, I have offloaded even basic numeric representations to libraries, but provide an injection feature that is similar to Philip Wadler's \"Views\" -- defining a translation from a kell calculus definition (say, Peano arithmetic) to a more efficient representation. The compiler provides a set of these from standard library structures to native structures, and then programmers can define injections from their own data structures and operations to standard library structures, because transitivity. There is a lot of ongoing work on Kilns -- from developing a type system, to implementing a data-parallel version of the core match operation in OpenCL, to simply learning the right way to use it. Or even moving away from the kell calculus entirely, which is already at least the third process calculus that this language (or at least its siblings) has been built upon.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"17 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134322626","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Fast Generic Dispatch for Common Lisp","authors":"R. Strandh","doi":"10.1145/2635648.2635654","DOIUrl":"https://doi.org/10.1145/2635648.2635654","url":null,"abstract":"We describe a technique for generic dispatch that is adapted to modern computers where accessing memory is potentially quite expensive. Instead of the traditional hashing scheme used by PCL [6], we assign a unique number to each class, and the dispatch consists of comparisons of the number assigned to an instance with a certain number of (usually small) constant integers. While our implementation (SICL) is not yet in a state where we are able to get exact performance figures, a conservative simulation suggests that our technique is significantly faster than the one used in SBCL, which uses PCL, and indeed faster than the technique used by most high-performance Common Lisp implementations. Furthermore, existing work [7] using a similar technique in the context of static languages suggests that perfomance can improve significantly compared to table-based techniques.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":" 10","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"113949822","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Eager Evaluation Isn't Eager Enough A Transformation Based Approach to Semantics-Directed Code Generation","authors":"Arthur Nunes-Harwitt","doi":"10.1145/2635648.2635652","DOIUrl":"https://doi.org/10.1145/2635648.2635652","url":null,"abstract":"An interpreter is a concise definition of the semantics of a programming language and is easily implemented. A compiler is more difficult to construct, but the code that it generates runs faster than interpreted code. This paper introduces rules for staging an interpreter so that it generates a compiler. An extended example suggests the utility of the technique. The rules are described formally and correctness is discussed. Finally, this technique is compared to staging and partial evaluation.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123614404","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}