The Grace Programming Language Draft Specification Version 0.132
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
The Development of Smalltalk Topic Paper #7
The Development of Smalltalk Topic Paper #7 Alex Laird Max Earn Peer CS-3210-01 Reviewer On Time/Format 1 2/4/09 Survey of Programming Languages Correct 5 Spring 2009 Clear 2 Computer Science, (319) 360-8771 Concise 2 [email protected] Grading Rubric Grading Total 10 pts ABSTRACT Dynamically typed languages are easier on the compiler because This paper describes the development of the Smalltalk it has to make fewer passes and the brunt of checking is done on programming language. the syntax of the code. Compilation of Smalltalk is just-in-time compilation, also known Keywords as dynamic translation. It means that upon compilation, Smalltalk code is translated into byte code that is interpreted upon usage and Development, Smalltalk, Programming, Language at that point the interpreter converts the code to machine language and the code is executed. Dynamic translations work very well 1. INTRODUCTION with dynamic typing. Smalltalk, yet another programming language originally developed for educational purposes and now having a much 5. IMPLEMENTATIONS broader horizon, first appeared publically in the computing Smalltalk has been implemented in numerous ways and has been industry in 1980 as a dynamically-typed object-oriented language the influence of many future languages such as Java, Python, based largely on message-passing in Simula and Lisp. Object-C, and Ruby, just to name a few. Athena is a Smalltalk scripting engine for Java. Little Smalltalk 2. EARLY HISTORY was the first interpreter of the programming language to be used Development for Smalltalk started in 1969, but the language outside of the Xerox PARC. -
Chapter 5 Type Declarations
Ch.5: Type Declarations Plan Chapter 5 Type Declarations (Version of 27 September 2004) 1. Renaming existing types . 5.2 2. Enumeration types . 5.3 3. Constructed types . 5.5 4. Parameterised/polymorphic types . 5.10 5. Exceptions, revisited . 5.12 6. Application: expression evaluation . 5.13 °c P. Flener/IT Dept/Uppsala Univ. FP 5.1 Ch.5: Type Declarations 5.1. Renaming existing types 5.1. Renaming existing types Example: polynomials, revisited Representation of a polynomial by a list of integers: type poly = int list ² Introduction of an abbreviation for the type int list ² The two names denote the same type ² The object [4,2,8] is of type poly and of type int list - type poly = int list ; type poly = int list - type poly2 = int list ; type poly2 = int list - val p:poly = [1,2] ; val p = [1,2] : poly - val p2:poly2 = [1,2] ; val p2 = [1,2] : poly2 - p = p2 ; val it = true : bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.2 Ch.5: Type Declarations 5.2. Enumeration types 5.2. Enumeration types Declaration of a new type having a finite number of values Example (weekend.sml) datatype months = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec datatype days = Mon | Tue | Wed | Thu | Fri | Sat | Sun fun weekend Sat = true | weekend Sun = true | weekend d = false - datatype months = Jan | ... | Dec ; datatype months = Jan | ... | Dec - datatype days = Mon | ... | Sun ; datatype days = Mon | ... | Sun - fun weekend ... ; val weekend = fn : days -> bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.3 Ch.5: Type Declarations 5.2. -
Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019
Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Jonathan Aldrich, Chair Heather Miller Alex Potanin, Victoria University of Wellington, NZ Submitted in partial fulfillment of the requirements for the degree of Master of Science. Copyright c 2019 Yu Xiang Zhu Keywords: Nominality, Wyvern, Dependent Object Types, Subtype Decidability Abstract This thesis presents Nominal Wyvern, a nominal type system that empha- sizes semantic separation for better usability. Nominal Wyvern is based on the dependent object types (DOT) calculus, which provides greater expressiv- ity than traditional object-oriented languages by incorporating concepts from functional languages. Although DOT is generally perceived to be nominal due to its path-dependent types, it is still a mostly structural system and relies on the free construction of types. This can present usability issues in a subtyping- based system where the semantics of a type are as important as its syntactic structure. Nominal Wyvern overcomes this problem by semantically separat- ing structural type/subtype definitions from ad hoc type refinements and type bound declarations. In doing so, Nominal Wyvern is also able to overcome the subtype undecidability problem of DOT by adopting a semantics-based sep- aration between types responsible for recursive subtype definitions and types that represent concrete data. The result is a more intuitive type system that achieves nominality and decidability while maintaining the expressiveness of F-bounded polymorphism that is used in practice. iv Acknowledgments This research would not have been possible without the support from the following in- dividuals. -
Cablelabs® Specifications Cablelabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317
CableLabs® Specifications CableLabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317 ISSUED Notice This CableLabs specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. You may download, copy, distribute, and reference the documents herein only for the purpose of developing products or services in accordance with such documents, and educational use. Except as granted by CableLabs in a separate written license agreement, no license is granted to modify the documents herein (except via the Engineering Change process), or to use, copy, modify or distribute the documents for any other purpose. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. To the extent this document contains or refers to documents of third parties, you agree to abide by the terms of any licenses associated with such third-party documents, including open source licenses, if any. Cable Television Laboratories, Inc. 2006-2016 CL-SP-CANN-DHCP-Reg-I13-160317 CableLabs® Specifications DISCLAIMER This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein. Any use or reliance on the information or opinion in this document is at the risk of the user, and CableLabs and its members shall not be liable for any damage or injury incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained in the document. -
Cross-Platform Language Design
Cross-Platform Language Design THIS IS A TEMPORARY TITLE PAGE It will be replaced for the final print by a version provided by the service academique. Thèse n. 1234 2011 présentée le 11 Juin 2018 à la Faculté Informatique et Communications Laboratoire de Méthodes de Programmation 1 programme doctoral en Informatique et Communications École Polytechnique Fédérale de Lausanne pour l’obtention du grade de Docteur ès Sciences par Sébastien Doeraene acceptée sur proposition du jury: Prof James Larus, président du jury Prof Martin Odersky, directeur de thèse Prof Edouard Bugnion, rapporteur Dr Andreas Rossberg, rapporteur Prof Peter Van Roy, rapporteur Lausanne, EPFL, 2018 It is better to repent a sin than regret the loss of a pleasure. — Oscar Wilde Acknowledgments Although there is only one name written in a large font on the front page, there are many people without which this thesis would never have happened, or would not have been quite the same. Five years is a long time, during which I had the privilege to work, discuss, sing, learn and have fun with many people. I am afraid to make a list, for I am sure I will forget some. Nevertheless, I will try my best. First, I would like to thank my advisor, Martin Odersky, for giving me the opportunity to fulfill a dream, that of being part of the design and development team of my favorite programming language. Many thanks for letting me explore the design of Scala.js in my own way, while at the same time always being there when I needed him. -
Blossom: a Language Built to Grow
Macalester College DigitalCommons@Macalester College Mathematics, Statistics, and Computer Science Honors Projects Mathematics, Statistics, and Computer Science 4-26-2016 Blossom: A Language Built to Grow Jeffrey Lyman Macalester College Follow this and additional works at: https://digitalcommons.macalester.edu/mathcs_honors Part of the Computer Sciences Commons, Mathematics Commons, and the Statistics and Probability Commons Recommended Citation Lyman, Jeffrey, "Blossom: A Language Built to Grow" (2016). Mathematics, Statistics, and Computer Science Honors Projects. 45. https://digitalcommons.macalester.edu/mathcs_honors/45 This Honors Project - Open Access is brought to you for free and open access by the Mathematics, Statistics, and Computer Science at DigitalCommons@Macalester College. It has been accepted for inclusion in Mathematics, Statistics, and Computer Science Honors Projects by an authorized administrator of DigitalCommons@Macalester College. For more information, please contact [email protected]. In Memory of Daniel Schanus Macalester College Department of Mathematics, Statistics, and Computer Science Blossom A Language Built to Grow Jeffrey Lyman April 26, 2016 Advisor Libby Shoop Readers Paul Cantrell, Brett Jackson, Libby Shoop Contents 1 Introduction 4 1.1 Blossom . .4 2 Theoretic Basis 6 2.1 The Potential of Types . .6 2.2 Type basics . .6 2.3 Subtyping . .7 2.4 Duck Typing . .8 2.5 Hindley Milner Typing . .9 2.6 Typeclasses . 10 2.7 Type Level Operators . 11 2.8 Dependent types . 11 2.9 Hoare Types . 12 2.10 Success Types . 13 2.11 Gradual Typing . 14 2.12 Synthesis . 14 3 Language Description 16 3.1 Design goals . 16 3.2 Type System . 17 3.3 Hello World . -
Project Overview 1 Introduction 2 a Quick Introduction to SOOL
CMSC 22600 Compilers for Computer Languages Handout 1 Autumn 2016 October 6, 2016 Project Overview 1 Introduction The project for the course is to implement a small object-oriented programming language, called SOOL. The project will consist of four parts: 1. the parser and scanner, which coverts a textual representation of the program into a parse tree representation. 2. the type checker, which checks the parse tree for type correctness and produces a typed ab- stract syntax tree (AST) 3. the normalizer, which converts the typed AST representation into a static single-assignment (SSA) representation. 4. the code generator, which takes the SSA representation and generates LLVM assembly code. Each part of the project builds upon the previous parts, but we will provide reference solutions for previous parts. You will implement the project in the Standard ML programming language and submission of the project milestones will be managed using Phoenixforge. Important note: You are expected to submit code that compiles and that is well documented. Points for project code are assigned 30% for coding style (documentation, choice of variable names, and program structure), and 70% for correctness. Code that does not compile will not receive any points for correctness. 2 A quick introduction to SOOL SOOL is a statically-typed object-oriented language. It supports single inheritance with nominal subtyping and interfaces with structural subtyping. The SOOL version of the classic Hello World program is class main () { meth run () -> void { system.print ("hello world\n"); } } Here we are using the predefined system object to print the message. Every SOOL program has a main class that must have a run function. -
Filename Extensions
Filename Extensions Generated 22 February 1999 from Filex database with 3240 items. ! # $ & ) 0 1 2 3 4 6 7 8 9 @ S Z _ a b c d e f g h i j k l m n o p q r s t u v w x y z ~ • ! .!!! Usually README file # .### Compressed volume file (DoubleSpace) .### Temp file (QTIC) .#24 Printer data file for 24 pin matrix printer (LocoScript) .#gf Font file (MetaFont) .#ib Printer data file (LocoScript) .#sc Printer data file (LocoScript) .#st Standard mode printer definitions (LocoScript) $ .$$$ Temporary file .$$f Database (OS/2) .$$p Notes (OS/2) .$$s Spreadsheet (OS/2) .$00 Pipe file (DOS) .$1 ZX Spectrum file in HOBETA format .$d$ Data (OS/2 Planner) .$db Temporary file (dBASE IV) .$ed Editor temporary file (MS C) .$ln TLink response file (Borland C++) .$o1 Pipe file (DOS) .$vm Virtual manager temporary file (Windows 3.x) & .&&& Temporary file ) .)2( LHA archiver temporary file (LHA) 0 .0 Compressed harddisk data (DoubleSpace) .000 Common filename extension (GEOS) .000 Compressed harddisk data (DoubleSpace) .001 Fax (Hayes JT FAX) (many) .075 75x75 dpi display font (Ventura Publisher) .085 85x85 dpi display font (Ventura Publisher) .091 91x91 dpi display font (Ventura Publisher) .096 96x96 dpi display font (Ventura Publisher) .0b Printer font with lineDraw extended character set (PageMaker) 1 .1 Unformatted manual page (Roff/nroff/troff/groff) .10x Bitmap graphics (Gemini 10x printer graphics file) .123 Data (Lotus123 97) .12m Smartmaster file (Lotus123 97) .15u Printer font with PI font set (PageMaker) .1st Usually README.1ST text 2 .24b Bitmap -
Distributive Disjoint Polymorphism for Compositional Programming
Distributive Disjoint Polymorphism for Compositional Programming Xuan Bi1, Ningning Xie1, Bruno C. d. S. Oliveira1, and Tom Schrijvers2 1 The University of Hong Kong, Hong Kong, China fxbi,nnxie,[email protected] 2 KU Leuven, Leuven, Belgium [email protected] Abstract. Popular programming techniques such as shallow embeddings of Domain Specific Languages (DSLs), finally tagless or object algebras are built on the principle of compositionality. However, existing program- ming languages only support simple compositional designs well, and have limited support for more sophisticated ones. + This paper presents the Fi calculus, which supports highly modular and compositional designs that improve on existing techniques. These im- provements are due to the combination of three features: disjoint inter- section types with a merge operator; parametric (disjoint) polymorphism; and BCD-style distributive subtyping. The main technical challenge is + Fi 's proof of coherence. A naive adaptation of ideas used in System F's + parametricity to canonicity (the logical relation used by Fi to prove co- herence) results in an ill-founded logical relation. To solve the problem our canonicity relation employs a different technique based on immediate substitutions and a restriction to predicative instantiations. Besides co- herence, we show several other important meta-theoretical results, such as type-safety, sound and complete algorithmic subtyping, and decidabil- ity of the type system. Remarkably, unlike F<:'s bounded polymorphism, + disjoint polymorphism in Fi supports decidable type-checking. 1 Introduction Compositionality is a desirable property in programming designs. Broadly de- fined, it is the principle that a system should be built by composing smaller sub- systems. -
Bs-6026-0512E.Pdf
THERMAL PRINTER SPEC BAS - 6026 1. Basic Features 1.) Type : PANEL Mounting or DESK top type 2.) Printing Type : THERMAL PRINT 3.) Printing Speed : 25mm / SEC 4.) Printing Column : 24 COLUMNS 5.) FONT : 24 X 24 DOT MATRIX 6.) Character : English, Numeric & Others 7.) Paper width : 57.5mm ± 0.5mm 8.) Character Size : 5times enlarge possible 9.) INTERFACE : CENTRONICS PARALLEL I/F SERIAL I/F 10.) DIMENSION : 122(W) X 90(D) X 129(H) 11.) Operating Temperature range : 0℃ - 50℃ 12.) Storage Temperature range : -20℃ - 70℃ 13.) Outlet Power : DC 12V ( 1.6 A )/ DC 5V ( 2.5 A) 14.) Application : Indicator, Scale, Factory automation equipments and any other data recording, etc.,, - 1 - 1) SERIAL INTERFACE SPECIFICATION * CONNECTOR : 25 P FEMALE PRINTER : 4 P CONNECTOR 3 ( TXD ) ----------------------- 2 ( RXD ) 2 2 ( RXD ) ----------------------- 1 ( TXD ) 3 7 ( GND ) ----------------------- 4 ( GND ) 5 DIP SWITCH BUAD RATE 1 2 3 ON ON ON 150 OFF ON ON 300 ON OFF ON 600 OFF OFF ON 1200 ON ON OFF 2400 OFF ON OFF 4800 ON OFF OFF 9600 OFF OFF OFF 19200 2) BAUD RATE SELECTION * PROTOCOL : XON / XOFF Type DIP SWITCH (4) ON : Combination type * DATA BIT : 8 BIT STOP BIT : 1 STOP BIT OFF: Complete type PARITY CHECK : NO PARITY * DEFAULT VALUE : BAUD RATE (9600 BPS) - 2 - PRINTING COMMAND * Explanation Command is composed of One Byte Control code and ESC code. This arrangement is started with ESC code which is connected by character & numeric code The control code in Printer does not be still in standardization (ESC Control Code). All printers have a code structure by themselves. -
A Survey of Technologies for Building Collaborative Virtual Environments
The International Journal of Virtual Reality, 2009, 8(1):53-66 53 A Survey of Technologies for Building Collaborative Virtual Environments Timothy E. Wright and Greg Madey Department of Computer Science & Engineering, University of Notre Dame, United States Whereas desktop virtual reality (desktop-VR) typically uses Abstract—What viable technologies exist to enable the nothing more than a keyboard, mouse, and monitor, a Cave development of so-called desktop virtual reality (desktop-VR) Automated Virtual Environment (CAVE) might include several applications? Specifically, which of these are active and capable display walls, video projectors, a haptic input device (e.g., a of helping us to engineer a collaborative, virtual environment “wand” to provide touch capabilities), and multidimensional (CVE)? A review of the literature and numerous project websites indicates an array of both overlapping and disparate approaches sound. The computing platforms to drive these systems also to this problem. In this paper, we review and perform a risk differ: desktop-VR requires a workstation-class computer, assessment of 16 prominent desktop-VR technologies (some mainstream OS, and VR libraries, while a CAVE often runs on building-blocks, some entire platforms) in an effort to determine a multi-node cluster of servers with specialized VR libraries the most efficacious tool or tools for constructing a CVE. and drivers. At first, this may seem reasonable: different levels of immersion require different hardware and software. Index Terms—Collaborative Virtual Environment, Desktop However, the same problems are being solved by both the Virtual Reality, VRML, X3D. desktop-VR and CAVE systems, with specific issues including the management and display of a three dimensional I. -
An Introduction to Lean
An Introduction to Lean Jeremy Avigad Leonardo de Moura Gabriel Ebner and Sebastian Ullrich Version 1fc176a, updated at 2017-01-09 14:16:26 -0500 2 Contents Contents 3 1 Overview 5 1.1 Perspectives on Lean ............................... 5 1.2 Where To Go From Here ............................. 12 2 Defining Objects in Lean 13 2.1 Some Basic Types ................................ 14 2.2 Defining Functions ................................ 17 2.3 Defining New Types ............................... 20 2.4 Records and Structures ............................. 22 2.5 Nonconstructive Definitions ........................... 25 3 Programming in Lean 27 3.1 Evaluating Expressions .............................. 28 3.2 Recursive Definitions ............................... 30 3.3 Inhabited Types, Subtypes, and Option Types . 32 3.4 Monads ...................................... 34 3.5 Input and Output ................................ 35 3.6 An Example: Abstract Syntax ......................... 36 4 Theorem Proving in Lean 38 4.1 Assertions in Dependent Type Theory ..................... 38 4.2 Propositions as Types .............................. 39 4.3 Induction and Calculation ............................ 42 4.4 Axioms ...................................... 45 5 Using Automation in Lean 46 6 Metaprogramming in Lean 47 3 CONTENTS 4 Bibliography 48 1 Overview This introduction offers a tour of Lean and its features, with a number of examples foryou to play around with and explore. If you are reading this in our online tutorial system, you can run examples like the one below by clicking the button that says “try it yourself.” #check "hello world!" The response from Lean appears in the small window underneath the editor text, and also in popup windows that you can read when you hover over the indicators in the left margin. Alternatively, if you have installed Lean and have it running in a stand-alone editor, you can copy and paste examples and try them there.