DOCSLIB.ORG

The Ceylon Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Ceylon Language The Ceylon Language Say more, more clearly Version: 1.3 Table of Contents Welcome to Ceylon ........................................................................................................................... vii 1. Introduction .................................................................................................................................. 1 1.1. Language overview ............................................................................................................... 1 1.1.1. Runtime and platform .................................................................................................. 1 1.2. Type system ......................................................................................................................... 1 1.2.1. Mixin inheritance ........................................................................................................ 2 1.2.2. Sum types, self types, and type families .......................................................................... 2 1.2.3. Simplified generics ..................................................................................................... 2 1.2.4. Union and intersection types ......................................................................................... 3 1.2.5. Type aliases and type inference ..................................................................................... 3 1.2.6. Metaprogramming ...................................................................................................... 4 1.3. Object-oriented programming .................................................................................................. 4 1.3.1. Class initialization and instantiation ............................................................................... 4 1.3.2. Functions, methods, values, and attributes ....................................................................... 5 1.3.3. Defaulted parameters and variadic parameters .................................................................. 5 1.3.4. First-class functions and higher-order programming .......................................................... 5 1.3.5. Naming conventions, annotations, and inline documentation ............................................... 5 1.3.6. Named arguments and tree-like structures ........................................................................ 6 1.3.7. Modularity ................................................................................................................ 6 1.4. Language module .................................................................................................................. 6 1.4.1. Operators and operator polymorphism ............................................................................ 6 1.4.2. Numeric and character types ......................................................................................... 6 1.4.3. Compile-time safety for null values and flow-sensitive typing ............................................. 7 1.4.4. Streams and comprehensions ........................................................................................ 7 1.4.5. Sequences and tuples ................................................................................................... 7 2. Lexical structure ............................................................................................................................ 9 2.1. Whitespace .......................................................................................................................... 9 2.2. Comments ........................................................................................................................... 9 2.3. Identifiers and keywords ........................................................................................................10 2.4. Literals ...............................................................................................................................11 2.4.1. Numeric literals .........................................................................................................11 2.4.2. Character literals .......................................................................................................13 2.4.3. String literals ............................................................................................................14 2.5. Operators and delimiters ........................................................................................................14 3. Type system ..................................................................................................................................16 3.1. Identifier naming ..................................................................................................................17 3.2. Types .................................................................................................................................17 3.2.1. Member distinctness ...................................................................................................18 3.2.2. Subtyping .................................................................................................................18 3.2.3. Union types ..............................................................................................................19 3.2.4. Intersection types .......................................................................................................19 3.2.5. The bottom type ........................................................................................................20 3.2.6. Principal typing .........................................................................................................21 3.2.7. Type expressions .......................................................................................................21 3.2.8. Type abbreviations .....................................................................................................22 3.2.9. Type inference ..........................................................................................................23 3.2.10. Type alias elimination ...............................................................................................24 3.3. Inheritance ..........................................................................................................................24 3.3.1. Inheritance and subtyping ............................................................................................25 3.3.2. Extension .................................................................................................................25 3.3.3. Satisfaction ...............................................................................................................26 3.4. Case enumeration and coverage ..............................................................................................27 3.4.1. Coverage ..................................................................................................................27 3.4.2. Cases .......................................................................................................................28 3.4.3. Generic enumerated types ............................................................................................29 3.4.4. Disjoint types ............................................................................................................29 3.5. Generic type parameters ........................................................................................................30 Project Ceylon: 1.3 ii The Ceylon Language 3.5.1. Type parameters and variance ......................................................................................31 3.5.2. Variance validation ....................................................................................................31 3.5.3. Generic type constraints ..............................................................................................33 3.6. Generic type arguments .........................................................................................................34 3.6.1. Type arguments and variance .......................................................................................35 3.6.2. Type argument substitution ..........................................................................................35 3.6.3. Type arguments and type constraints .............................................................................35 3.6.4. Applied types and and variance ....................................................................................36 3.6.5. Type argument inference .............................................................................................37 3.7. Principal instantiations and polymorphism ................................................................................39 3.7.1. Inherited instantiations ................................................................................................40 3.7.2. Type argument distinctness ..........................................................................................40 3.7.3. Principal instantiation inheritance .................................................................................40 3.7.4. Principal instantiation of a supertype .............................................................................41 3.7.5. Refinement ...............................................................................................................42 3.7.6. Qualified types
Load more

Recommended publications
  • 5. Data Types
    IEEE FOR THE FUNCTIONAL VERIFICATION LANGUAGE e Std 1647-2011 5. Data types The e language has a number of predefined data types, including the integer and Boolean scalar types common to most programming languages. In addition, new scalar data types (enumerated types) that are appropriate for programming, modeling hardware, and interfacing with hardware simulators can be created. The e language also provides a powerful mechanism for defining OO hierarchical data structures (structs) and ordered collections of elements of the same type (lists). The following subclauses provide a basic explanation of e data types. 5.1 e data types Most e expressions have an explicit data type, as follows: — Scalar types — Scalar subtypes — Enumerated scalar types — Casting of enumerated types in comparisons — Struct types — Struct subtypes — Referencing fields in when constructs — List types — The set type — The string type — The real type — The external_pointer type — The “untyped” pseudo type Certain expressions, such as HDL objects, have no explicit data type. See 5.2 for information on how these expressions are handled. 5.1.1 Scalar types Scalar types in e are one of the following: numeric, Boolean, or enumerated. Table 17 shows the predefined numeric and Boolean types. Both signed and unsigned integers can be of any size and, thus, of any range. See 5.1.2 for information on how to specify the size and range of a scalar field or variable explicitly. See also Clause 4. 5.1.2 Scalar subtypes A scalar subtype can be named and created by using a scalar modifier to specify the range or bit width of a scalar type.
    [Show full text]
  • Dotty Phantom Types (Technical Report)
    Dotty Phantom Types (Technical Report) Nicolas Stucki Aggelos Biboudis Martin Odersky École Polytechnique Fédérale de Lausanne Switzerland Abstract 2006] and even a lightweight form of dependent types [Kise- Phantom types are a well-known type-level, design pattern lyov and Shan 2007]. which is commonly used to express constraints encoded in There are two ways of using phantoms as a design pattern: types. We observe that in modern, multi-paradigm program- a) relying solely on type unication and b) relying on term- ming languages, these encodings are too restrictive or do level evidences. According to the rst way, phantoms are not provide the guarantees that phantom types try to en- encoded with type parameters which must be satised at the force. Furthermore, in some cases they introduce unwanted use-site. The declaration of turnOn expresses the following runtime overhead. constraint: if the state of the machine, S, is Off then T can be We propose a new design for phantom types as a language instantiated, otherwise the bounds of T are not satisable. feature that: (a) solves the aforementioned issues and (b) makes the rst step towards new programming paradigms type State; type On <: State; type Off <: State class Machine[S <: State] { such as proof-carrying code and static capabilities. This pa- def turnOn[T >: S <: Off] = new Machine[On] per presents the design of phantom types for Scala, as im- } new Machine[Off].turnOn plemented in the Dotty compiler. An alternative way to encode the same constraint is by 1 Introduction using an implicit evidence term of type =:=, which is globally Parametric polymorphism has been one of the most popu- available.
    [Show full text]
  • Chapter 5: Substitutes for C Constructs
    CHAPTER 5 Substitutes for C Constructs THE Java programming language shares many similarities with the C program- ming language, but several C constructs have been omitted. In most cases, it’s obvi- ous why a C construct was omitted and how to make do without it. This chapter suggests replacements for several omitted C constructs whose replacements are not so obvious. The common thread that connects the items in this chapter is that all of the omitted constructs are data-oriented rather than object-oriented. The Java pro- gramming language provides a powerful type system, and the suggested replace- ments take full advantage of that type system to deliver a higher quality abstraction than the C constructs they replace. Even if you choose to skip this chapter, it’s probably worth reading Item 21, which discusses the typesafe enum pattern, a replacement for C’s enum construct. This pattern is not widely known at the time of this writing, and it has several advan- tages over the methods currently in common use. Item 19: Replace structures with classes The C struct construct was omitted from the Java programming language because a class does everything a structure does and more. A structure merely groups multi- ple data fields into a single object; a class associates operations with the resulting object and allows the data fields to be hidden from users of the object. In other words, a class can encapsulate its data into an object that is accessed solely by its methods, allowing the implementor the freedom to change the representation over time (Item 12).
    [Show full text]
  • Beaaqualogic Enterprise Security™®
    BEAAquaLogic Enterprise Security™® Policy Managers Guide Version 2.6 Document Revised: April 2007 Contents 1. Introduction Document Scope and Audience. 1-1 Guide to this Document. 1-2 Related Documentation . 1-2 Contact Us! . 1-3 2. Security Policies Overview What is an AquaLogic Enterprise Security Policy? . 2-1 Closed-world Security Environment . 2-2 Policy Components . 2-3 Resources. 2-4 Virtual Resources . 2-6 Resource Attributes . 2-6 Privilege Groups. 2-6 Privileges . 2-6 Identities . 2-7 Identity Attributes. 2-8 Groups . 2-8 Users. 2-9 Roles. 2-10 Policies. 2-10 Role Mapping Policies . 2-10 Authorization Policies . 2-12 Delegation Policies. 2-13 Summary of Policy Differences . 2-14 Policy Managers Guide v Declarations. 2-14 Constants . 2-15 Enumerated Types . 2-15 Attributes . 2-15 Evaluation Functions . 2-15 3. Writing Policies Policy Implementation: Main Steps . 3-1 Access Decision Process . 3-4 Authentication Service. 3-4 Role Mapping Service . 3-4 Authorization Service . 3-5 Credential Mapping Service. 3-5 Authorization and Role Mapping Engine . 3-5 Using the Administration Console to Write Policies . 3-7 Administration Console Overview. 3-7 Defining Resources . 3-8 Virtual Resources . 3-11 Resource Attributes. 3-12 Privileges . 3-12 Privilege Groups . 3-13 Defining Identities . 3-14 Identity Attributes . 3-16 Groups. 3-16 Users . 3-17 Roles . 3-18 Writing Authorization and Role Mapping Policies . 3-19 Role Mapping Policies . 3-20 vi Policy Managers Guide Authorization Policies. 3-20 Role Mapping Policy Reports . 3-21 Authorization Policy Reports . 3-21 Defining Declarations. 3-22 Binding Policies .
    [Show full text]
  • Data Types Enumerated Types
    CS 1044 Intro Programming in C++ Fall 2002 August 22, 2002 Data Types 9. Types 1 data type: a collection of values and the definition of one or more operations that can be performed on those values C++ includes a variety of built-in or base data types: short, int, long, float, double, char, etc. The values are ordered and atomic. C++ supports several mechanisms for aggregate data types: arrays, structures, classes. These allow complex combinations of other types as single entities. C++ also supports other mechanisms that allow programmers to define their own custom data types: enum types and typedefs. Computer Science Dept Va Tech August, 2002 Intro Programming in C++ ©1995-2002 Barnette ND & McQuain WD Enumerated Types 9. Types 2 An enumerated type is defined by giving a name for the type and then giving a list of labels, which are the only values that a variable of that type is allowed to have. Enumerated types allow the creation of specialized types that support the use of meaningful labels within a program. They promote code readability with very little overhead in memory or runtime cost. enum Month {JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC}; enum Season {WINTER, SPRING, SUMMER, FALL}; enum Hemisphere {NORTH, SOUTH, EAST, WEST}; Month Mon; Season Period; Hemisphere Region; ... if (Mon == JAN && Region == NORTH) Period = WINTER; An enumerated type is allowed to have up to 256 values and a variable of an enumerated type will occupy one byte of memory. It is an error for the same label to be listed as a value for two different enumerated types.
    [Show full text]
  • Object-Oriented Enumerated Type Facility
    Europäisches Patentamt *EP001400895A2* (19) European Patent Office Office européen des brevets (11) EP 1 400 895 A2 (12) EUROPEAN PATENT APPLICATION (43) Date of publication: (51) Int Cl.7: G06F 9/44 24.03.2004 Bulletin 2004/13 (21) Application number: 03255511.2 (22) Date of filing: 03.09.2003 (84) Designated Contracting States: (72) Inventors: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR • Bloch, Joshua J. HU IE IT LI LU MC NL PT RO SE SI SK TR San José, CA 95129 (US) Designated Extension States: • Gafter, Neal M. AL LT LV MK San José, CA 95129 (US) (30) Priority: 09.09.2002 US 237941 (74) Representative: Davies, Simon Robert D Young & Co, (71) Applicant: Sun Microsystems, Inc. 21 New Fetter Lane Santa Clara, California 95054 (US) London, EC4A 1DA (GB) (54) Object-oriented enumerated type facility (57) A system and method are provided that facili- tate use of an object-oriented enumerated type within a computer program. During operation, the system re- ceives source code for the computer program. The source code contains a declaration for an enumerated type. This declaration specifies a fixed number of enu- meration constants that comprise the enumerated type. Next, the system defines the enumerated type using a class defined within an object-oriented programming language. The class includes a constant for each enu- meration constant specified in the declaration. If the declaration additionally contains one or more method declarations, these methods are present on the defined class. EP 1 400 895 A2 Printed by Jouve, 75001 PARIS (FR) EP 1 400 895 A2 Description Field of the Invention 5 [0001] The present invention relates to computer systems and to programming languages, and more specifically, to a method and an apparatus for facilitating the use of an object-oriented enumerated type within a programming lan- guage.
    [Show full text]
  • Enumerated Types
    Enumerated Types CSE160, Computer Science A: Honors Stony Brook University http://www.cs.stonybrook.edu/~cse160 1 Enumerated Types An enumerated type defines a list of enumerated values Each value is an identifier enum Day{SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY}; enum TrafficLight { RED, GREEN, YELLOW } A value of an enumerated type is like a constant and so, by convention, is spelled with all uppercase letters Also, by convention, an enumerated type is named like a class with first letter of each word capitalized Once a type is defined, you can declare a variable of that type: Day day; TrafficLight t; The variable day can hold one of the values defined in the enumerated type Day or null, but nothing else 2 (c) Pearson Education, Inc. & Paul Fodor (CS Stony Brook) Enumerated Types The enumerated values can be accessed using the syntax EnumeratedTypeName.valueName For example, the following statement assigns enumerated value Monday to variable day: Day day = Day.MONDAY; Using enumerated values (e.g., Day.MONDAY) rather than literal integer values (e.g., 0, 1, 2, 3, and so on) can make program easier to read and maintain An enumerated type is treated as a special class, so an enumerated type variable is therefore a reference variable An enumerated type is a subtype of the Object class (inherits all the methods in the Object class) and the Comparable interface (has the compareTo method in the Comparable interface) 3 (c) Pearson Education, Inc. & Paul Fodor (CS Stony Brook) Enumerated Types The following methods are defined for any enumerated object: public String name(); Returns a name of the value for the object (e.g.
    [Show full text]
  • Webassembly Specification
    WebAssembly Specification Release 1.1 WebAssembly Community Group Andreas Rossberg (editor) Mar 11, 2021 Contents 1 Introduction 1 1.1 Introduction.............................................1 1.2 Overview...............................................3 2 Structure 5 2.1 Conventions.............................................5 2.2 Values................................................7 2.3 Types.................................................8 2.4 Instructions.............................................. 11 2.5 Modules............................................... 15 3 Validation 21 3.1 Conventions............................................. 21 3.2 Types................................................. 24 3.3 Instructions.............................................. 27 3.4 Modules............................................... 39 4 Execution 47 4.1 Conventions............................................. 47 4.2 Runtime Structure.......................................... 49 4.3 Numerics............................................... 56 4.4 Instructions.............................................. 76 4.5 Modules............................................... 98 5 Binary Format 109 5.1 Conventions............................................. 109 5.2 Values................................................ 111 5.3 Types................................................. 112 5.4 Instructions.............................................. 114 5.5 Modules............................................... 120 6 Text Format 127 6.1 Conventions............................................
    [Show full text]
  • Software II: Principles of Programming Languages
    Software II: Principles of Programming Languages Lecture 6 – Data Types Some Basic Definitions • A data type defines a collection of data objects and a set of predefined operations on those objects • A descriptor is the collection of the attributes of a variable • An object represents an instance of a user- defined (abstract data) type • One design issue for all data types: What operations are defined and how are they specified? Primitive Data Types • Almost all programming languages provide a set of primitive data types • Primitive data types: Those not defined in terms of other data types • Some primitive data types are merely reflections of the hardware • Others require only a little non-hardware support for their implementation The Integer Data Type • Almost always an exact reflection of the hardware so the mapping is trivial • There may be as many as eight different integer types in a language • Java’s signed integer sizes: byte , short , int , long The Floating Point Data Type • Model real numbers, but only as approximations • Languages for scientific use support at least two floating-point types (e.g., float and double ; sometimes more • Usually exactly like the hardware, but not always • IEEE Floating-Point Standard 754 Complex Data Type • Some languages support a complex type, e.g., C99, Fortran, and Python • Each value consists of two floats, the real part and the imaginary part • Literal form real component – (in Fortran: (7, 3) imaginary – (in Python): (7 + 3j) component The Decimal Data Type • For business applications (money)
    [Show full text]
  • 1 Intro to ML
    1 Intro to ML 1.1 Basic types Need ; after expression - 42 = ; val it = 42: int -7+1; val it =8: int Can reference it - it+2; val it = 10: int - if it > 100 then "big" else "small"; val it = "small": string Different types for each branch. What will happen? if it > 100 then "big" else 0; The type checker will complain that the two branches have different types, one is string and the other is int If with then but no else. What will happen? if 100>1 then "big"; There is not if-then in ML; must use if-then-else instead. Mixing types. What will happen? What is this called? 10+ 2.5 In many programming languages, the int will be promoted to a float before the addition is performed, and the result is 12.5. In ML, this type coercion (or type promotion) does not happen. Instead, the type checker will reject this expression. div for integers, ‘/ for reals - 10 div2; val it =5: int - 10.0/ 2.0; val it = 5.0: real 1 1.1.1 Booleans 1=1; val it = true : bool 1=2; val it = false : bool Checking for equality on reals. What will happen? 1.0=1.0; Cannot check equality of reals in ML. Boolean connectives are a bit weird - false andalso 10>1; val it = false : bool - false orelse 10>1; val it = true : bool 1.1.2 Strings String concatenation "University "^ "of"^ " Oslo" 1.1.3 Unit or Singleton type • What does the type unit mean? • What is it used for? • What is its relation to the zero or bottom type? - (); val it = () : unit https://en.wikipedia.org/wiki/Unit_type https://en.wikipedia.org/wiki/Bottom_type The boolean type is inhabited by two values: true and false.
    [Show full text]
  • C++ DATA TYPES Rialspo Int.Co M/Cplusplus/Cpp Data Types.Htm Copyrig Ht © Tutorialspoint.Com
    C++ DATA TYPES http://www.tuto rialspo int.co m/cplusplus/cpp_data_types.htm Copyrig ht © tutorialspoint.com While doing prog ramming in any prog ramming lang uag e, you need to use various variables to store various information. Variables are nothing but reserved memory locations to store values. This means that when you create a variable you reserve some space in memory. You may like to store information of various data types like character, wide character, integ er, floating point, double floating point, boolean etc. Based on the data type of a variable, the operating system allocates memory and decides what can be stored in the reserved memory. Primitive Built-in Types: C++ offer the prog rammer a rich assortment of built-in as well as user defined data types. Following table lists down seven basic C++ data types: Type Keyword Boolean bool Character char Integ er int Floating point float Double floating point double Valueless void Wide character wchar_t Several of the basic types can be modified using one or more of these type modifiers: sig ned unsig ned short long The following table shows the variable type, how much memory it takes to store the value in memory, and what is maximum and minimum vaue which can be stored in such type of variables. Type Typical Bit Width Typical Rang e char 1byte -127 to 127 or 0 to 255 unsig ned char 1byte 0 to 255 sig ned char 1byte -127 to 127 int 4bytes -2147483648 to 2147483647 unsig ned int 4bytes 0 to 4294967295 sig ned int 4bytes -2147483648 to 2147483647 short int 2bytes -32768 to 32767 unsig ned short int Rang e 0 to 65,535 sig ned short int Rang e -32768 to 32767 long int 4bytes -2,147,483,647 to 2,147,483,647 sig ned long int 4bytes same as long int unsig ned long int 4bytes 0 to 4,294,967,295 float 4bytes +/- 3.4e +/- 38 (~7 dig its) double 8bytes +/- 1.7e +/- 308 (~15 dig its) long double 8bytes +/- 1.7e +/- 308 (~15 dig its) wchar_t 2 or 4 bytes 1 wide character The sizes of variables mig ht be different from those shown in the above table, depending on the compiler and the computer you are using .
    [Show full text]
  • Foundations of Path-Dependent Types
    Foundations of Path-Dependent Types Nada Amin∗ Tiark Rompf †∗ Martin Odersky∗ ∗EPFL: {first.last}@epfl.ch yOracle Labs: {first.last}@oracle.com Abstract 1. Introduction A scalable programming language is one in which the same A scalable programming language is one in which the same concepts can describe small as well as large parts. Towards concepts can describe small as well as large parts. Towards this goal, Scala unifies concepts from object and module this goal, Scala unifies concepts from object and module systems. An essential ingredient of this unification is the systems. An essential ingredient of this unification is to concept of objects with type members, which can be ref- support objects that contain type members in addition to erenced through path-dependent types. Unfortunately, path- fields and methods. dependent types are not well-understood, and have been a To make any use of type members, programmers need a roadblock in grounding the Scala type system on firm the- way to refer to them. This means that types must be able ory. to refer to objects, i.e. contain terms that serve as static We study several calculi for path-dependent types. We approximation of a set of dynamic objects. In other words, present µDOT which captures the essence – DOT stands some level of dependent types is required; the usual notion for Dependent Object Types. We explore the design space is that of path-dependent types. bottom-up, teasing apart inherent from accidental complexi- Despite many attempts, Scala’s type system has never ties, while fully mechanizing our models at each step.
    [Show full text]