Table 3 - uploaded by Manuel Carro
Content may be subject to copyright.
Source publication
In order to achieve competitive performance, abstract machines for Prolog and
related languages end up being large and intricate, and incorporate
sophisticated optimizations, both at the design and at the implementation
levels. At the same time, efficiency considerations make it necessary to use
low-level languages in their implementation. This mak...
Context in source publication
Context 1
... our selection seems intuitively appropriate, as it uses two different encodings for two different families of transformations, one which affects the bytecode language itself, and another one which changes the way these bytecode operands are interpreted. Table 3 relates the bits in these two groups, using the same order as in the plots. Every benchmark was run several times on each emulator to make timings stable. ...
Citations
... Unikernels [16], for example, are very promising on this area. Also, other virtual machine optimizations have been studied in the context of programing languages [23]. ...
Container technologies, like Docker, are becoming increasingly popular. Containers provide exceptional developer experience because containers offer lightweight isolation and ease of software distribution. Containers are also widely used in production environments, where a different set of challenges arise such as security, networking, service discovery and load balancing. Container cluster management tools, such as Kubernetes, attempt to solve these problems by introducing a new control layer with the container as the unit of deployment. However, adding a new control layer is an extra configuration step and an additional potential source of runtime errors. The virtual machine technology offered by cloud providers is more mature and proven in terms of security, networking, service discovery and load balancing. However, virtual machines are heavier than containers for local development, are less flexible for resource allocation, and suffer longer boot times. This paper presents an alternative to containers that enjoy the best features of both approaches: (1) the use of mature, proven cloud vendor technology; (2) no need for a new control layer; and (3) as lightweight as containers. Our solution is i2kit, a deployment tool based on the immutable infrastructure pattern, where the virtual machine is the unit of deployment. The i2kit tool accepts a simplified format of Kubernetes Deployment Manifests in order to reuse Kubernetes' most successful principles, but it creates a lightweight virtual machine for each Pod using Linuxkit. Linuxkit alleviates the drawback in size that using virtual machines would otherwise entail, because the footprint of Linuxkit is approximately 60MB. Finally, the attack surface of the system is reduced since Linuxkit only installs the minimum set of OS dependencies to run containers, and different Pods are isolated by hypervisor technology.
... Albert et al. (2012) use a similar approach to cost analysis. Morales et al. (2015) explore the use of a logic programming language for the implementation of efficient abstract machines and runtime systems. To this end they use a Prolog variant with certain imperative features (mutable variables) that enables translation into efficient C-style code while still allowing for high-level program transformations, such as partial evaluation of instruction definitions. ...
Many recent analyses for conventional imperative programs begin by
transforming programs into logic programs, capitalising on existing LP analyses
and simple LP semantics. We propose using logic programs as an intermediate
program representation throughout the compilation process. With restrictions
ensuring determinism and single-modedness, a logic program can easily be
transformed to machine language or other low-level language, while maintaining
the simple semantics that makes it suitable as a language for program analysis
and transformation. We present a simple LP language that enforces determinism
and single-modedness, and show that it makes a convenient program
representation for analysis and transformation.
We present in a tutorial way some ideas developed in the context of the Ciao Prolog system that we believe could be useful for the future evolution of Prolog. We concentrate primarily on one area: the use of assertions with types, modes, and other properties, and how the unique characteristics of Prolog have made early advances possible in the area of combining static and dynamic language features. However, we also address briefly some other issues related to extending the expressiveness and functionality of the language.KeywordsPrologStatic LanguagesDynamic LanguagesTypesModesAssertionsVerificationTestingTest GenerationLanguage Extensions
Both logic programming in general and Prolog in particular have a long and fascinating history, intermingled with that of many disciplines they inherited from or catalyzed. A large body of research has been gathered over the last 50 years, supported by many Prolog implementations. Many implementations are still actively developed, while new ones keep appearing. Often, the features added by different systems were motivated by the interdisciplinary needs of programmers and implementors, yielding systems that, while sharing the “classic” core language, in particular, the main aspects of the ISO-Prolog standard, also depart from each other in other aspects. This obviously poses challenges for code portability. The field has also inspired many related, but quite different languages that have created their own communities. This article aims at integrating and applying the main lessons learned in the process of evolution of Prolog. It is structured into three major parts. First, we overview the evolution of Prolog systems and the community approximately up to the ISO standard, considering both the main historic developments and the motivations behind several Prolog implementations, as well as other logic programming languages influenced by Prolog. Then, we discuss the Prolog implementations that are most active after the appearance of the standard: their visions, goals, commonalities, and incompatibilities. Finally, we perform a SWOT analysis in order to better identify the potential of Prolog and propose future directions along with which Prolog might continue to add useful features, interfaces, libraries, and tools, while at the same time improving compatibility between implementations.
(Under consideration for publication in Theory and Practice of Logic Programming)
Both logic programming in general, and Prolog in particular, have a long and fascinating history, inter-mingled with that of many disciplines they inherited from or catalyzed. A large body of research has been gathered over the last 50 years, supported by many Prolog implementations. Many implementations are still actively developed, while new ones keep appearing. Often, the features added by different systems were motivated by the interdisciplinary needs of programmers and implementors, yielding systems that, while sharing the "classic" core language, and, in particular, the main aspects of the ISO-Prolog standard, also depart from each other in other aspects. This obviously poses challenges for code portability. The field has also inspired many related, but quite different languages that have created their own communities. This article aims at integrating and applying the main lessons learned in the process of evolution of Prolog. It is structured into three major parts. Firstly, we overview the evolution of Prolog systems and the community approximately up to the ISO standard, considering both the main historic developments and the motivations behind several Prolog implementations, as well as other logic programming languages influenced by Prolog. Then, we discuss the Prolog implementations that are most active after the appearance of the standard: their visions, goals, commonalities, and incompatibilities. Finally, we perform a SWOT analysis in order to better identify the potential of Prolog, and propose future directions along which Prolog might continue to add useful features, interfaces, libraries, and tools, while at the same time improving compatibility between implementations.
