Empowering the Experts: High-Assurance, High-Performance, High-Level Design with Cryptol

Total Page:16

File Type:pdf, Size:1020Kb

Empowering the Experts: High-Assurance, High-Performance, High-Level Design with Cryptol Empowering the Experts: High-Assurance, High-Performance, High-Level Design with Cryptol Sally A. Browning, Magnus Carlsson, Levent Erkök, John Matthews, Brad Martin, Sean Weaver domain-specific language (DSL) is a programming language targeted at producing solutions in a given problem domain by enabling subject- Amatter experts to design solutions in terms they are familiar with and at a level of abstraction that makes most sense to them. In addition, a good DSL opens the way for powerful tool support: simulations for design exploration; automatic testing and generation of test harnesses; generation of highly specialized code for multiple targets; and generation of formal evidence for correctness, safety, and security properties. Cryptographer as designer or has insufficient throughput, or..., the into a test harness, and blasted with test You are a highly skilled crypto- hardware designer iteratively tweaks the vectors. If it works, great. Otherwise, the grapher charged with designing a custom, design until it is “good enough.” search begins to find the error. But how do you know if it still state-of-the-art encryption solution for And what if a security hole; for works the way you intended? protecting mission-critical information. example, a malicious counter or a back There are explicit and competing Typically, the design is fabricated door; was introduced? Would you even requirements for the implementation— (if it is an ASIC—application-specific know? throughput, size, power utilization, integrated circuit) or loaded into an FPGA operation temperature, etc.—that may (field-programmable gate array), placed There must be a better way. affect the implementation. You produce a design and want to see how it matches up with the implementation requirements. How would you proceed? Figure 1: Traditionally, the crypto developer must be highly Typically, you find an expert trained and expert at balancing hardware designer who translates your a myriad of often conflicting requirements. algorithm into VHDL (a hardware description language), and then runs proprietary tools to characterize the Image Source: Galois, Inc. implementation. If it uses too much power, 1 From Section 3.1 of the AES definition [2]: The input and output for the AES algorithm each consist of sequences of 128 bits... The Cipher Key for the AES algorithm is a sequence of 128, 192 or 256 bits. Other input, output and Cipher Key lengths are not permitted by this standard. In Cryptol: Cryptol: A better way {k}{k >= 2, 4 >= k) => ([128],[64*k]) -> [128] The Cryptol specification language Image Source: Galois, Inc. was designed for the National Security Figure 2: The constraints and requirements from the Advanced Encryption Standard Agency (NSA) as a public standard for (AES) [2] can be translated directly into Cryptol types, as shown above. The colored specifying cryptographic algorithms [1]. text shows the linkage between English constraint and Cryptol type. The Cryptol tools provide a development path for cryptographic modules across the plaintext initial entire software process, from specification permutation des : ([64] ,[ 56]) -> [[]64]; and implementation to verification and des (pt, key) = permute (FP, last) L0 R0 where { certification. Cryptol tools significantly K1 pt’ = permute (IP, pt); ^ f reduce overall life-cycle costs by iv = [| round (lr, key, rnd) addressing the key cost drivers in the || rnd <- [0 .. 15] R =L ^ (R ,K ) || lr <- [(split pt’)] # iv L1=R0 1 0 f 0 1 deployment of cryptography. |]; K 2 last = join (swap (iv @ 15)); ^ f Rapid design cycle swap [a b] = [b a]; }; L =R R =L ^f(R ,K ) Cryptol specifications are 2 1 2 1 1 2 fully executable, allowing designers round : ([2][32], [56], [4]) -> [2][32]; L =R R =L ^ (R ,K ) round([l r], key, rnd) = [r (l^f(r, kx))] 15 14 15 14 f 14 15 K to experiment with their programs where { 16 incrementally as their designs evolve. kx = expand(key, rnd); ^ f f(r,k) = permute(PP, SBox(k^permute(EP, r))); The Cryptol tools support a refinement }; R16=L15^f(R15,K16) L16=R15 methodology that bridges the conceptual inverse initial gap between specification and low-level Image Source: Galois, Inc. permutation implementation, thereby reducing time ciphertext to market. For example, Cryptol allows Figure 3: The Data Encryption Standard (DES) algorithm is a block cipher that engineers and mathematicians to program uses a 56-bit symmetric key. The diagram above is taken from the Standard [3]. Cryptol uses parallel stream comprehensions to interleave data and lazy evaluation cryptographic algorithms on FPGAs as if to encapsulate multiple computational stages in a single statement. Colors and they were writing software. shapes are used to help relate the program text to the diagram. Details of the language can be found in [4] and at www.cryptol.net. Reusable specification The Cryptol tools provide a predicates constrain the range of values platform-neutral specification language Design: The Cryptol the quantified size variables can accept; that generates implementations on multi- language here, k must be between 2 and 4. To the ple platforms. Cryptol tools can generate Cryptol [1] is a pure functional right of the =>, we see the actual type. software implementations, hardware language built on top of a polymorphic The function has two inputs: a 128- implementations, and for mal models for type system that has been extended with bit word containing the plaintext and a verification, all from a single Cryptol size polymorphism and arithmetic type 64*k-bit wide key. The function outputs program. predicates designed to capture constraints that arise naturally in cryptographic another 128-bit word, the ciphertext. Note Accelerated certification specifications. the precise correspondence of the type to the English description in the standard. A Cryptol reference specification Figure 2 shows an excerpt from becomes the formal documentation for the AES specification [2] that describes Figure 3 shows a Cryptol code the cryptographic module, eliminating the generator inputs and outputs, and the snippet—a specification for the core of the need for separate and voluminous corresponding Cryptol definition. The the DES algorithm. Note the compact English descriptions. In addition, Cryptol text to the left of => ([128],[64*k]) in the mathematical function notation and the verification tools show functionalCryptol definition describes quantified definition of sequence structures and bit equivalence between the specification type variables and predicates on them. In sizes. The Cryptol Reference Manual [4] and the implementation at various stages this case, the type is size polymorphic, has many more examples as well as a of the toolchain. relying on the size variable k. The detailed description of the language. 2 Implement: operations are to be applied. But there High-level exploration of The Cryptol FPGA the resemblance ends. Sequences, which the design space Type 1 cryptographic devices appear repeatedly in the mathematical Good design is always at the root of protect information of national descriptions of crypto algorithms, great performance. One of the key factors importance. The information assurance have many different instantiations as in Cryptol’s performance results is its standards for such products are hardware. At one extreme, the sequence ability to explore the implementation correspondingly high. In addition, crypto can be spread out in space as side-by- design space at a very high level. A modernization requirements mandate field side parallelism. At the other extreme, Cryptol developer can experiment with programmability, and various operational the sequence can be laid out in time as many different microarchitectures in the requirements call for a reduced space, consecutive values held in a register, or course of a few days, covering ground weight, and power footprint. over many registers in a pipeline. Many that would otherwise take weeks or FPGAs offer a compelling platform combinations of these are also possible. months using traditional methods. A to address these needs. They are field The Cryptol FPGA generator uses a variety of implementation approaches can updatable by design, offer tremendous wide variety of engineering heuristics to be modeled and characterized quickly. performance potential, and have fewer pick an appropriate translation of a Cryptol For example, at the Cryptol level, nonrecurring engineering costs than function to an FPGA configuration that a straightforward idiom identifies pipe- traditional ASIC designs. will make effective and efficient use of lined functional units in hardware. Recall However, FPGA development the silicon. The user can also provide the specification for DES shown in Figure still requires the considerable time and pragmas (compiler commands) about 3. The designer has created a pipelined talents of skilled hardware designers, space/time mappings, thereby guiding the version of the round function by hand which increases development time translation process without compromising by factoring the high-level Cryptol and costs. Mainstream design tools the integrity of the original specification. specification, as shown in Figure 4. The supplied by FPGA vendors have more The declarative quality of Cryptol, Cryptol FPGA generator produces an in common with VLSI (very-large- which makes Cryptol a good specification efficient pipelined circuit, also shown in scale integration) design tools than with language, also plays a key role in the Figure 4 on page 8. modern programming environments. effectiveness of automatic generation High-level design exploration pro- These design tools automatically limit of FPGA cores. In contrast, the inherent vides a profound advantage in the devel- the user population to designers trained in sequentiality of mainstream program- opment of high-performance algorithms VLSI design. ming languages makes them a poor match (or in algorithms meeting other design The Cryptol FPGA generator for the highly parallel nature of FPGAs. constraints). The key is the speed with introduces a new design flow that allows which the developer is able to iterate the Creating high-performance engineers and mathematicians to program design, the bottleneck of hardware design.
Recommended publications
  • Practical Reflection and Metaprogramming for Dependent
    Practical Reflection and Metaprogramming for Dependent Types David Raymond Christiansen Advisor: Peter Sestoft Submitted: November 2, 2015 i Abstract Embedded domain-specific languages are special-purpose pro- gramming languages that are implemented within existing general- purpose programming languages. Dependent type systems allow strong invariants to be encoded in representations of domain-specific languages, but it can also make it difficult to program in these em- bedded languages. Interpreters and compilers must always take these invariants into account at each stage, and authors of embedded languages must work hard to relieve users of the burden of proving these properties. Idris is a dependently typed functional programming language whose semantics are given by elaboration to a core dependent type theory through a tactic language. This dissertation introduces elabo- rator reflection, in which the core operators of the elaborator are real- ized as a type of computations that are executed during the elab- oration process of Idris itself, along with a rich API for reflection. Elaborator reflection allows domain-specific languages to be imple- mented using the same elaboration technology as Idris itself, and it gives them additional means of interacting with native Idris code. It also allows Idris to be used as its own metalanguage, making it into a programmable programming language and allowing code re-use across all three stages: elaboration, type checking, and execution. Beyond elaborator reflection, other forms of compile-time reflec- tion have proven useful for embedded languages. This dissertation also describes error reflection, in which Idris code can rewrite DSL er- ror messages before presenting domain-specific messages to users, as well as a means for integrating quasiquotation into a tactic-based elaborator so that high-level syntax can be used for low-level reflected terms.
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]
  • A Fast, Verified, Cross-Platform Cryptographic Provider
    EverCrypt: A Fast, Verified, Cross-Platform Cryptographic Provider Jonathan Protzenko∗, Bryan Parnoz, Aymeric Fromherzz, Chris Hawblitzel∗, Marina Polubelovay, Karthikeyan Bhargavany Benjamin Beurdouchey, Joonwon Choi∗x, Antoine Delignat-Lavaud∗,Cedric´ Fournet∗, Natalia Kulatovay, Tahina Ramananandro∗, Aseem Rastogi∗, Nikhil Swamy∗, Christoph M. Wintersteiger∗, Santiago Zanella-Beguelin∗ ∗Microsoft Research zCarnegie Mellon University yInria xMIT Abstract—We present EverCrypt: a comprehensive collection prone (due in part to Intel and AMD reporting CPU features of verified, high-performance cryptographic functionalities avail- inconsistently [78]), with various cryptographic providers able via a carefully designed API. The API provably supports invoking illegal instructions on specific platforms [74], leading agility (choosing between multiple algorithms for the same functionality) and multiplexing (choosing between multiple im- to killed processes and even crashing kernels. plementations of the same algorithm). Through abstraction and Since a cryptographic provider is the linchpin of most zero-cost generic programming, we show how agility can simplify security-sensitive applications, its correctness and security are verification without sacrificing performance, and we demonstrate crucial. However, for most applications (e.g., TLS, cryptocur- how C and assembly can be composed and verified against rencies, or disk encryption), the provider is also on the critical shared specifications. We substantiate the effectiveness of these techniques with
    [Show full text]
  • Comparative Programming Languages CM20253
    We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily
    [Show full text]
  • Crypthol: Game-Based Proofs in Higher-Order Logic∗ David A
    J Cryptol (2020) 33:494–566 https://doi.org/10.1007/s00145-019-09341-z CryptHOL: Game-Based Proofs in Higher-Order Logic∗ David A. Basin · Andreas Lochbihler · S. Reza Sefidgar Institute of Information Security, Department of Computer Science, ETH Zurich, Universitätstrasse 6, 8092 Zurich, Switzerland [email protected] [email protected] reza.sefi[email protected] Communicated by Ran Canetti. Received 24 July 2017 / Revised 3 September 2019 Online publication 6 January 2020 Abstract. Game-based proofs are a well-established paradigm for structuring secu- rity arguments and simplifying their understanding. We present a novel framework, CryptHOL, for rigorous game-based proofs that is supported by mechanical theorem proving. CryptHOL is based on a new semantic domain with an associated functional programming language for expressing games. We embed our framework in the Is- abelle/HOL theorem prover and, using the theory of relational parametricity, we tailor Isabelle’s existing proof automation to game-based proofs. By basing our framework on a conservative extension of higher-order logic and providing automation support, the resulting proofs are trustworthy and comprehensible, and the framework is extensible and widely applicable. We evaluate our framework by formalising different game-based proofs from the literature and comparing the results with existing formal-methods tools. Keywords. Provable security, Game-based proofs, Theorem proving, Higher-order logic, Isabelle/HOL. 1. Introduction Problem Context. In the 1980s, Provable Security emerged as a way of using reduction arguments to put the security of public-key cryptography on a firm scientific footing. But difficulties in applying this idea raised doubts on the credibility of the resulting proofs [38].
    [Show full text]
  • Arxiv:2102.01644V2 [Cs.PL] 9 Jun 2021 08Ascainfrcmuigmachinery
    Functional Pearl: Zero-Cost, Meta-Programmed, Dependently-Typed Stateful Functors in F★ JONATHAN PROTZENKO, Microsoft Research, USA SON HO, Inria, France Writing code is hard; proving it correct is even harder. As the scale of verified software projects reaches new heights, the problem of efficiently verifying large amounts of software becomes more and more salient. Nowhere is this issue more evident than in the context of verified cryptographic libraries. To achieve feature- parity and be competitive with unverified cryptographic libraries, a very large number of algorithms and APIs need to be verified. However, the task is oftentimes repetitive, and factoring out commonality between algorithms is fraught with difficulties, requiring until now a significant amount of manual effort. This paper shows how a judicious combination of known functional programming techniques leads to an ★ order-of-magnitude improvement in the amount of verified code produced by the popular HACL crypto- graphic library, without compromising performance. We review three techniques that build upon each other, in order of increasing sophistication. First, we use dependent types to crisply capture the specification and state machine of a block algorithm, a cryptographic notion that was until now only informally and impre- cisely specified. Next, we rely on partial evaluation to author a higher-order, stateful functor that transforms any unsafe block API into a safe counterpart. Finally, we rely on elaborator reflection to automate the very process of authoring a functor, using a code-rewriting tactic. This culminates in a style akin to templatized C++ code, but relying on a userland tactic and partial evaluation, rather than built-in compiler support.
    [Show full text]
  • Chapter 2 Domain-Specific Languages for Cryptography
    Domain-specific Languages for Cryptographic Software ii Abstract Cryptography plays an important role in our society, essentially because it is used in critical computer systems that must work properly, even in the face of errors or human mistakes. Banking or health care are examples of areas which use hardware and software that must work in every situation. The main goal of the use of cryptography in those systems is to achieve information security, which in most cases is sensitive. In the last few years, programming languages that focus on a particular domain emerged, denominated as Domain-specific Languages (DSLs). Two DSLs for cryptography appeared, Cryptol and CAO, both aiming to increase the produc- tivity of developers, but also to improve the communication between them and domain experts. Cryptol is a functional language and has an associated toolkit composed by a verification suite and compilation back ends to languages such as C or VHDL (a hardware description language). CAO is an imperative language, with a syntax similar to C’s and also has an associated toolkit with tools that allows, for instance, the introduction of higher-order operations into the language. In this work, these two DSLs for cryptography will be analysed, focusing on its features and how they can re-target a published algorithm into a specific imple- mentation. Furthermore, it was developed a compiler tool that aims to translate CAO source code into Cryptol, in order to compile it afterwards to VHDL. Finally, a case study focusing on elliptic curve cryptography, was used to compare the two DSLs and to test the developed tool.
    [Show full text]
  • Case Studies in Cryptol a Study of Domain Specific Languages for DSP Algorithms Master of Science Thesis in Computer Science and Engineering
    Case Studies in Cryptol A study of domain specific languages for DSP algorithms Master of Science Thesis in Computer Science and Engineering MUHAMMAD ASIF Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Göteborg, Sweden, November 2009 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Case Studies in Cryptol A study of domain specific languages for DSP algorithms MUHAMMAD ASIF © MUHAMMAD ASIF, November 2009. Examiner: PATRIK JANSSON Department of Computer Science and Engineering Chalmers University of Technology SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden October 2009 Abstract Digital Signal Processing (DSP) has become part of many electronic applications these days; confluent to this, Domain Specific Languages (DSLs) are prevailing among practitioners of many engineering domains.
    [Show full text]
  • Vale: Verifying High-Performance Cryptographic Assembly Code Barry Bond and Chris Hawblitzel, Microsoft Research; Manos Kapritsos, University of Michigan; K
    Vale: Verifying High-Performance Cryptographic Assembly Code Barry Bond and Chris Hawblitzel, Microsoft Research; Manos Kapritsos, University of Michigan; K. Rustan M. Leino and Jacob R. Lorch, Microsoft Research; Bryan Parno, Carnegie Mellon University; Ashay Rane, The University of Texas at Austin; Srinath Setty, Microsoft Research; Laure Thompson, Cornell University https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/bond This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX Vale: Verifying High-Performance Cryptographic Assembly Code Barry Bond?, Chris Hawblitzel?, Manos Kapritsosy, K. Rustan M. Leino?, Jacob R. Lorch?, Bryan Parnoz, Ashay Ranex, Srinath Setty?, Laure Thompson{ ? Microsoft Research y University of Michigan z Carnegie Mellon University x The University of Texas at Austin { Cornell University Abstract sub BODY_00_15{ my ($i,$a,$b,$c,$d,$e,$f,$g,$h)=@_; High-performance cryptographic code often relies on $code.=<<___ if ($i<16); complex hand-tuned assembly language that is cus- #if __ARM_ARCH__>=7 tomized for individual hardware platforms. Such code @ ldr $t1,[$inp],#4@ $i # if $i==15 is difficult to understand or analyze. We introduce anew str $inp,[sp,#17*4]@ make room for $t4 programming language and tool called Vale that supports # endif flexible, automated verification of high-performance as- eor $t0,$e,$e,ror#`$Sigma1[1]-$Sigma1[0]` sembly code. The Vale tool transforms annotated assem- add $a,$a,$t2@h+=Maj(a,b,c) from the past eor $t0,$t0,$e,ror#`$Sigma1[2]-$Sigma1[0]`@Sigma1(e) bly language into an abstract syntax tree (AST), while # ifndef __ARMEB__ also generating proofs about the AST that are verified via rev $t1,$t1 an SMT solver.
    [Show full text]
  • List of Programming Languages
    List of programming languages The aim of this list of programming languages is to 1 A include all notable programming languages in existence, both those in current use and historical ones, in alpha- • A# .NET betical order, except for dialects of BASIC, esoteric pro- gramming languages, and markup languages. • A# (Axiom) Contents : • A-0 System • A+ • A • A++ • B • ABAP • C • ABC • D • ABC ALGOL • E • • F ABSET • • G ABSYS • H • ACC • I • Accent • J • Ace DASL • K • ACL2 • L • Avicsoft • M • ACT-III • N • Action! • O • ActionScript • P • Ada • Q • Adenine • R • Agda • S • • T Agilent VEE • • U Agora • V • apple • W • AIMMS • X • Alef • Y • ALF • Z • ALGOL 58 • See also • ALGOL 60 1 2 3 C • ALGOL 68 2 B • ALGOL W • B • • Alice Babbage • Bash • Alma-0 • BASIC • AmbientTalk • bc • Amiga E • BCPL • AMOS • BeanShell • Batch (Windows/Dos) • AMPL • Bertrand • AngularJS • BETA • Apex (Salesforce.com) • Bistro • APL • BitC • BLISS • App Inventor for Android’s visual block language • Blockly • AppleScript • BlooP • Arc • Boo • ARexx • Boomerang • • Argus Bourne shell (including bash and ksh) • BREW • AspectJ • BPEL • Assembly language • Business Basic • ATS • Ateji PX 3 C • AutoHotkey • C • C-- • Autocoder • C++ – ISO/IEC 14882 • AutoIt • C# – ISO/IEC 23270 • AutoLISP / Visual LISP • C/AL • Averest • Caché ObjectScript • C Shell • AWK • Caml • Axum • Cayenne • Active Server Pages • CDuce • ASP.NET • Cecil 3 • Cesil • COMIT • Céu • Common Intermediate Language (CIL) • Ceylon • Common Lisp (also known as CL) • CFEngine • COMPASS • CFML • Component
    [Show full text]
  • Domain Specific Languages a Path to High Assurance Solutions CASE STUDY
    Cryptol: The Language of Cryptography Domain Specific Languages A path to high assurance solutions CASE STUDY DOMAIN SPECIFIC LANGUAGES A domain-specific language (DSL) is a programming language targeted at producing solutions in a given problem domain (as opposed to general-purpose programming languages). The idea is to empower subject-matter experts by allowing them to design solutions in terms they are familiar with and at a level of abstraction that makes most sense to them. Galois has been a leader designing DSLs for a variety of domains, including cryptography, operating system security policy, communication routing policy, and more. APPROACH In addition, a good DSL opens the way for powerful tool support: simulations for design exploration, automatic testing and automatic generation of test harnesses, generation of highly specialized code for multiple targets, and generation of formal evidence for correctness, safety and security properties. These kinds of tools are possible for general-purpose languages as well, but generality limits how far one can go. The fact that a DSL is restricted to a particular problem domain allows for profound and often unexpectedly superior results, mainly because one can apply the wealth of domain-specific heuristics and expert knowledge available for that domain directly in these tools. BENEFITS Formalizing system requirements in a DSL. Verification and validation. With a traditional approach, system level requirements are usually Any system needs good testing. The same features that enable a expressed in natural language documents. A well-designed DSL system designer to experiment with her designs via simulation allows the domain expert to quickly prototype their system and also enable the generation of comprehensive test harnesses, explore the design space through experiments and simulation.
    [Show full text]
  • Haskell (Programming Language) 1 Haskell (Programming Language)
    Haskell (programming language) 1 Haskell (programming language) Haskell Paradigm(s) functional, lazy/non-strict, modular Designed by Simon Peyton Jones, Lennart Augustsson, Dave Barton, Brian Boutel, Warren Burton, Joseph Fasel, Kevin Hammond, Ralf Hinze, Paul Hudak, John Hughes, Thomas Johnsson, Mark Jones, John Launchbury, Erik Meijer, John Peterson, Alastair Reid, Colin Runciman, Philip Wadler Appeared in 1990 Stable release Haskell 2010 / July 2010 Preview release Announced as Haskell 2014 Typing discipline static, strong, inferred Major GHC, Hugs, NHC, JHC, Yhc, UHC implementations Dialects Helium, Gofer Influenced by Clean, FP, Gofer, Hope and Hope+, Id, ISWIM, KRC, Lisp, Miranda, ML and Standard ML, Orwell, SASL, SISAL, Scheme [1] [2] [2] [2] Influenced Agda, Bluespec, C++11/Concepts, C#/LINQ, CAL,Wikipedia:Citation needed Cayenne, Clean, Clojure, [2] [2] CoffeeScript, Curry, Elm, Epigram,Wikipedia:Citation needed Escher,Wikipedia:Citation needed F#, Frege, Isabelle, [2] [2] Java/Generics, Kaya,Wikipedia:Citation needed LiveScript, Mercury, Omega,Wikipedia:Citation needed Perl 6, [2] [2] [2] Python, Qi,Wikipedia:Citation needed Scala, Swift, Timber,Wikipedia:Citation needed Visual Basic 9.0 OS Cross-platform Filename .hs, .lhs extension(s) [3] Website haskell.org Haskell /ˈhæskəl/ is a standardized, general-purpose purely functional programming language, with non-strict semantics and strong static typing.[4] It is named after logician Haskell Curry.[5] History Following the release of Miranda by Research Software Ltd, in 1985, interest in lazy functional languages grew: by 1987, more than a dozen non-strict, purely functional programming languages existed. Of these, Miranda was the most widely used, but was proprietary software. At the conference on Functional Programming Languages and Computer Architecture (FPCA '87) in Portland, Oregon, a meeting was held during which participants formed a strong consensus that a committee should be formed to define an open standard for such languages.
    [Show full text]