DOCSLIB.ORG

(Ventures Into) Dependent Type Theory with Reductions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
(Ventures Into) Dependent Type Theory with Reductions (Ventures into) Dependent Type Theory with Reductions Sam Speight [email protected] Spring 2019 Last updated July 7, 2020 In this note we introduce dependent type theory with reductions and categories with ordered families, the former being an internal language for the latter. This is motivated by the desire to extend to dependent type theory Gallier’s [Gal95] semantic method for proving metatheoretic properties of type theories involving reduction, which requires se- mantics that distinguishes judgementally equal objects and instead models reductions between them. 1 Introduction and motivation In [Gal95], Gallier presents a method for proving properties that involve reduction of terms of simply typed ¸-calculus and system F; instantiating his method, he proves confluence and strong normalisation for each of these type theories. Gallier’s motivation is to render the (Tait-Girard) “reducibility" method in more semantic terms. Much of the work is carried out at the level of pre-applicative ¯-structures, novel structures that serve to interpret well-typed terms and reductions between them (and so distinguish between terms that are judgemen- tally equal/convertible). Gallier mentions that he attempted to lift his method to dependent type theory, though ran into a problem that ‘has to do with type-conversion rules: a term no longer has a unique type, and we run into a coherence problem in attempting to define the meaning of term by induction on typing-derivations’; getting round this problem is described as ‘the most pressing open problem’ [Gal95, p. 364]. As far as we understand, the issue is to get a good notion of pre-applicative ¯-structures for the dependent setting. In this note, we introduce categories with ordered families (CwOFs), a natural higher- dimensional generalisation of Dybjer’s categories with families (CwFs) [Dyb95]. We believe that CwOFs could play the role of pre-applicative ¯-structures in a lifting of Gallier’s method to dependent type theory. To interpret type theory in CwOFs, as in CwFs, a partial interpre- tation function is given taking untyped syntax to the relevant part of a CwOF; after this it is proved that the interpretation function is defined on well-typed syntax, as is usual when in- terpreting dependent type theory (see [Hof97]. In this way, Gallier’s problem is circumvented. The internal language of CwOFs is a type theory that we call dependent type theory with reductions (DTTwR). As the aim is to give a model of dependent type theory that models reductions between terms and types (reductions can occur between types when types may depend on terms), and so distinguishes between terms and types that are convertible in de- pendent type theory as usually formulated (DTT, which we take to be something like that presented in [Hof97]), this must of course be reflected in DTTwR. Thus we have a notion of judgemental reduction, and we replace computation rules (the ¯-rule for ¦-types, for in- stance) as judgemental equalities with computation rules as judgemental reductions (we do 1 retain a notion of judgemental equality, but this has rather a different role than it usually does). However, due to the dependency of types on terms, modifying judgemental equality has an effect on the typing of terms. Thus, DTTwR bears a non-trivial relationship to DTT. We are yet to relate DTTwR to DTT and untyped reduction, as well as carry out the development of Gallier’s method for dependent type theory using CwOFs. We give some thoughts on the first of these tasks in 4.2 Future work. 2 Dependent type theory with reductions We work with a relatively straightforward type theory, which has one closed ground type G0, one other ground type G1 depending on terms of type G0 and ¦-types. Neither of the ground types are taken to have any term constructors, thus the only term constructors we have are c SUB for ¸-abstraction, application and coercion A,A0 (t) (see the rule in Figure1). (In this way we have types genuinely depending on terms.) As well as the usual judgements for well-typed contexts, types and terms, and judgemen- tal equality for contexts, types and terms, we have judgemental reduction for types ¡ A ` ) A0 type and terms ¡ t t 0 : A, with the intuitive meaning that, in the first case, say: in ` ) context ¡ the term t of type A reduces to the term t 0 of type A. Judgemental reduction is meant to capture the reflexive transitive closure of ¯-reduction acting in all contexts (we are not concerned with ´ here). The typing rules are given in Figure1 (p. 11), with the omission of the usual strucutral rules, the ususal rules saying that judgemental equality is a congruence on type and term for- mers and the usual rules for ¦-formation, ¸-abstraction and application (see [Hof97, §2]. Im- portantly, judgemental reduction is not symmetric, and we do not make the ¯-rule a judge- mental equality, but a judgemental reduction. The SUB rule (for “subsumption”, due to its likeness to the eponymous rule in subtyping disciplines) coerces a type to a “lower", more reduced, type. Note that whenever we have ¡ t t 0 : A we are careful in making sure that t and t 0 should be well-typed with type A in ` ) context ¡ (and similarly for types)—it is not as simple as repeating the rues for judgemental equality but without symmetry. For example, in the -¦ rule, when giving conditions under ) which Q B reduces t Q B , B and B are compared in context ,x : A; but B expects (x:A) (x:A0) 0 0 ¡ 0 the variable x to have type A0, and so in B 0 we replace x by its coercion down to the type A0. The last two rules allow coercions to be pushed inside ¸ and App. Note that we use fully annotated syntax. However, we take the view that annotations are annotations: they are for the purpose of rigorously interpreting the syntax into the semantics and therefore do not contribute to reductions. 3 Categories with ordered families Recall that a CwF [Dyb95] (again, see also [Hof97], which we rely on for results and notation, often without explicit mention) involves a functor Cop Fam, ! where C is a category (with a terminal object) and Fam is the category of set indexed families of sets. In moving from CwFs to CwOFs, we “bump-up” the dimension of each of the above components—and add to the comprehension axiom that is also required of a CwF. As we have a proof-irrelevant notion of judgemental reduction, we need only add extra layers of preordered structure. First we describe the bumped-up version of Fam. Definition 3.1. The category OFam (for “ordered families”) is given by the following. 2 • Objects are triples ¡ ¢ I,(Pi )i I ,(ci i )(i i ) Mor(I) , 2 ) 0 ) 0 2 where I and each of the Pi are preorders (with a morphism from a to b in some pre- order denoted by a b), and the ci i : Pi Pi are monotone functions such that: ) ) 0 ! 0 ci i idP , ) Æ i ci i ci i ci i . 0) 00 ± ) 0 Æ ) 00 The ci i are the semantic coercion functions. ) 0 • A morphism (I,(Pi ),ci i ) (J,Q j ,c j j )) is a pair: ) 0 ! ) 0 ¡ ¢ f : I J,(fi : Pi Q f (i))i I , ! ! 2 where f and each fi are monotone , such that the following square commutes. ci i ) 0 Pi Pi 0 fi f i0 Q f (i) c Q f (i) f (i)(i0) Composition and identities are as in Fam: the composition of (f ,(fi )) : (I,(Pi ),(ci i )) ) 0 ! (J,(Q j ),(c j j )) and (g,(gi )) : (J,(Q j ),(c j j )) (K ,(Rk ),(ck k )) is given by: ) 0 0 ) 0 ! ) 0 (g,(g )) (f ,(f )) : (g f : I K ,g f : P R ). j ± i Æ ! f (i) i i ! g(f (i)) • A 2-cell (f ,(fi )) (g,(gi )) : (I,(Pi ),ci i ) (J,(Q j ),(c j j ))) is determined pointwise ) ) 0 ! ) 0 in the codomain; that is, there is a 2-cell (f ,(f )) (g,(g )) whenever: i ) i (i) i i 0 I. f (i) g(i 0) J, and 8 ) 2 ) 2 (ii) i i 0 I and p Pi ,p0 Pi such that ci i (p) p0 Pi we have that: 8 ) 2 8 2 2 0 ) 0 ) 2 0 c f (i) g(i )(fi (p)) gi (p0) Qg(i ). ) 0 ) 0 2 0 y We use this category in the definition of CwOFs as follows. Definition 3.2. A category with ordered families is given by a preordered 2-category C (in which a 2-cell between f and g is denoted f g) with a (1-)terminal object and a preordered ) 2-functor F : Cop OFam, ! ¡ ¢ (where, like with CwFs, we write F ¡ as Ty(¡),(Tm(¡, A))A Ty(¡),(cA A )A A Ty(¡) and we 2 ) 0 ) 02 write both components of the morphism (Ty,Tm)(f : ¡ ¢) as ( ){f }; 2-cells—as well as ! ¡ preorder relations—are aslways written with ), such that the following comprehension ax- ) iom is satisfied. For any ¡ C and A Ty(¡) there is an object ¡.A C and a morphism p(A): ¡.A A and 2 2 2 ! semantic term v Tm(¡.A, A{p(A)}) such that for any f : ¢ ¡ and t Tm(¢, A{f }) there is A 2 ! 2 a unique morphism f ,t : ¢ ¡.A such that the following commutes. h iA ! v A ¡.A ( ){ f ,t A } ¡ h i p(A) f ,t A h i t ¢ ¡ f 3 (This much is the comprehension axiom for CwFs.) Moreover, whenever A A0 Ty(¡) ) 2 we have a unique morphism r (A, A0): ¡.A ¡.A0 in C such that p(A0) r (A, A0) p(A) and ! ± Æ v A {r (A, A0)} cA A (v A) and whenever t t 0 Tm(¢, A{f }) then f ,t A f ,t 0 A.
Load more

Recommended publications
  • Type-Safe Composition of Object Modules*
    International Conference on Computer Systems and Education I ISc Bangalore Typ esafe Comp osition of Ob ject Mo dules Guruduth Banavar Gary Lindstrom Douglas Orr Department of Computer Science University of Utah Salt LakeCity Utah USA Abstract Intro duction It is widely agreed that strong typing in We describ e a facility that enables routine creases the reliability and eciency of soft typ echecking during the linkage of exter ware However compilers for statically typ ed nal declarations and denitions of separately languages suchasC and C in tradi compiled programs in ANSI C The primary tional nonintegrated programming environ advantage of our serverstyle typ echecked ments guarantee complete typ esafety only linkage facility is the ability to program the within a compilation unit but not across comp osition of ob ject mo dules via a suite of suchunits Longstanding and widely avail strongly typ ed mo dule combination op era able linkers comp ose separately compiled tors Such programmability enables one to units bymatching symb ols purely byname easily incorp orate programmerdened data equivalence with no regard to their typ es format conversion stubs at linktime In ad Such common denominator linkers accom dition our linkage facility is able to automat mo date ob ject mo dules from various source ically generate safe co ercion stubs for com languages by simply ignoring the static se patible encapsulated data mantics of the language Moreover com monly used ob ject le formats are not de signed to incorp orate source language typ e
    [Show full text]
  • 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]
  • Python Programming
    Python Programming Wikibooks.org June 22, 2012 On the 28th of April 2012 the contents of the English as well as German Wikibooks and Wikipedia projects were licensed under Creative Commons Attribution-ShareAlike 3.0 Unported license. An URI to this license is given in the list of figures on page 149. If this document is a derived work from the contents of one of these projects and the content was still licensed by the project under this license at the time of derivation this document has to be licensed under the same, a similar or a compatible license, as stated in section 4b of the license. The list of contributors is included in chapter Contributors on page 143. The licenses GPL, LGPL and GFDL are included in chapter Licenses on page 153, since this book and/or parts of it may or may not be licensed under one or more of these licenses, and thus require inclusion of these licenses. The licenses of the figures are given in the list of figures on page 149. This PDF was generated by the LATEX typesetting software. The LATEX source code is included as an attachment (source.7z.txt) in this PDF file. To extract the source from the PDF file, we recommend the use of http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ utility or clicking the paper clip attachment symbol on the lower left of your PDF Viewer, selecting Save Attachment. After extracting it from the PDF file you have to rename it to source.7z. To uncompress the resulting archive we recommend the use of http://www.7-zip.org/.
    [Show full text]
  • Type Conversion ,Type Casting, Operator Precedence and Associativity in C
    Type Conversion ,Type Casting, Operator Precedence and Associativity in C Gaurav Kr. suman 4/30/20 MAT09 The type conversion in C is basically converting one type of data type to other to perform some operation. The conversion is done only between those datatypes wherein the conversion is possible There are two types of type conversion: This type of conversion is usually performed by the compiler when necessary without any commands by the user. Thus it is also called "Automatic Type Conversion". • Done by the compiler on its own, without any external trigger from the user. • Generally takes place when in an expression more than one data type is present. In such condition type conversion (type promotion) takes place to avoid lose of data. • All the data types of the variables are upgraded to the data type of the variable with largest data type. Now, let’s focus on some examples to further understand about type conversions in C. Example 1 int a = 20; double b = 20.5; a + b; Here, first operand is int type and other is of type double. So, as per rule, the variable a will be converted to double. Therefore, the final answer is double a + b = 40.500000. Example 2 char ch='a'; int a =13; a+c; Here, first operand is char type and other is of type int. So, as per rule , the char variable will be converted to int type during the operation and the final answer will be of type int. We know the ASCII value for ch is 97.
    [Show full text]
  • Object Oriented Pogramming with C++
    OBJECT ORIENTED POGRAMMING WITH C++ 1. What is type conversion? Type Conversion is the process of converting one predefined type into another type. When variables of one type are mixed with variables of another type, a type conversion will occur. C++ facilitates the type conversion into the following two forms: Implicit Type Conversion: An implicit type conversion is a conversion performed by the compiler without programmer's intervention. It is applied whenever different data types are intermixed in an expression, so as not to lose information short x=6000; int y; y=x; // data type short variable x is converted to int and is assigned to the integer variable y. Explicit Type Conversion: The explicit conversion of an operand to a specific type is called type casting. An explicit type conversion is user-defined that forces an expression to be of specific type. Syntax: (type) expression #include <iostream.h> void main( ) { int a; float b, c; cout << "Enter the value of a:"; cin >> a; cout << "Enter the value of b:"; cin >> b; c = float(a)+b; cout << "The value of c is:" << c; getch(); } In the above program “a” is declared as integer and “b” and “c” are declared as float. In the type conversion statement namely c = float (a) +b; The variable a of type integer is converted into float type and so the value 10 is converted as 10.0 and then is added with the float variable b with value 12.5 giving a resultant float variable c with value as 22.5 2. Why C++ is called OOP language? M.VIJAY .
    [Show full text]
  • VHDL Type Conversion | Bitweenie
    VHDL Type Conversion | BitWeenie http://www.bitweenie.com/listings/vhdl-type-conversion/ Home About Electrical Engineer Jobs Request Topic Resources Home » VHDL Type Conversion VHDL Type Conversion Posted by Shannon Hilbert in Verilog / VHDL on 2-10-13 Any given VHDL FPGA design may have multiple VHDL types being used. The most common VHDL types used in synthesizable VHDL code are std_logic, std_logic_vector, signed, unsigned, and integer. Because VHDL is a strongly-typed language, most often differing types cannot be used in the same expression. In cases where you can directly combine two types into one expression, you are really leaving it up to the compiler or synthesis tool to determine how the expression should behave, which is a dangerous thing to do. This article will discuss the following concepts: 1. Type casting and conversion functions. 2. The importance of using the appropriate type. 3. Common uses and examples. VHDL Type Cast and Conversion Functions The picture below illustrates how to convert between the most common VHDL types. Type casting is used to move between the std_logic_vector type and the signed and unsigned types. 1 --signal definitions 2 signal slv : std_logic_vector(7 downto 0); 3 signal s : signed(7 downto 0); 4 signal us : unsigned(7 downto 0); 5 6 --FROM std_logic_vector TO signed/unsigned 1 de 5 07/10/2015 14:58 VHDL Type Conversion | BitWeenie http://www.bitweenie.com/listings/vhdl-type-conversion/ 7 sgn <= signed(slv); 8 usgn <= unsigned(slv); 9 10-- FROM signed/unsigned TO std_logic_vector 11svl <= std_logic_vector(sgn); 12svl <= std_logic_vector(usgn); Functions are used to move between signed and unsigned types and the integer type.
    [Show full text]
  • N1592 Explicit Conversion Operators
    Document Number: SC22/WG21/N1592=04-0032 Date: 2004-2-13 Author: Lois Goldthwaite Email: [email protected] Explicit Conversion Operators This paper proposes a small change in C++ grammar to permit the function-specifier 'explicit' to be applied to the definition of a user-defined conversion operator. The semantic effect is to inhibit automatic conversions in situations where they may not have been intended. The Problem One of the design principles of C++ is that the language does not enforce a different syntax for user-defined types and built-in primitive types. A variable of either category can be passed by value (assuming the programmer has not intentionally disabled this), and a variable of any type can be passed by reference. The compiler will perform automatic promotions and conversions, if necessary, when numeric types are used as function parameters or when differing types are combined with an operator (int to long, signed to unsigned, float to double, etc.). Similarly, the programmer can write conversion functions for user-defined types, so that the conversions will take place transparently. This is a feature, and A Good Thing, as it decreases the number of overloaded functions which would otherwise be needed (D&E 3.6.1). In Modern C++ Design, Alexandrescu says, "User-defined conversions in C++ have an interesting history. Back in the 1980s, when user-defined conversions were introduced, most programmers considered them a great invention. User-defined conversions promised a more unified type system, expressive semantics, and the ability to define new types that were indistinguishable from built-in ones.
    [Show full text]
  • Polymorphism
    Polymorphism A closer look at types.... Chap 8 polymorphism º comes from Greek meaning ‘many forms’ In programming: Def: A function or operator is polymorphic if it has at least two possible types. Polymorphism i) OverloaDing Def: An overloaDeD function name or operator is one that has at least two Definitions, all of Different types. Example: In Java the ‘+’ operator is overloaDeD. String s = “abc” + “def”; +: String * String ® String int i = 3 + 5; +: int * int ® int Polymorphism Example: Java allows user DefineD polymorphism with overloaDeD function names. bool f (char a, char b) { return a == b; f : char * char ® bool } bool f (int a, int b) { f : int * int ® bool return a == b; } Note: ML Does not allow function overloaDing Polymorphism ii) Parameter Coercion Def: An implicit type conversion is calleD a coercion. Coercions usually exploit the type-subtype relationship because a wiDening type conversion from subtype to supertype is always DeemeD safe ® a compiler can insert these automatically ® type coercions. Example: type coercion in Java Double x; x = 2; the value 2 is coerceD from int to Double by the compiler Polymorphism Parameter coercion is an implicit type conversion on parameters. Parameter coercion makes writing programs easier – one function can be applieD to many subtypes. Example: Java voiD f (Double a) { ... } int Ì double float Ì double short Ì double all legal types that can be passeD to function ‘f’. byte Ì double char Ì double Note: ML Does not perform type coercion (ML has no notion of subtype). Polymorphism iii) Parametric Polymorphism Def: A function exhibits parametric polymorphism if it has a type that contains one or more type variables.
    [Show full text]
  • Primitive Data, Variables, and Expressions; Simple Conditional Execution
    Unit 2, Part 1 Primitive Data, Variables, and Expressions; Simple Conditional Execution Computer Science S-111 Harvard University David G. Sullivan, Ph.D. Overview of the Programming Process Analysis/Specification Design Implementation Testing/Debugging Example Problem: Adding Up Your Change • Let's say that we have a bunch of coins of various types, and we want to figure out how much money we have. • Let’s begin the process of developing a program that does this. Step 1: Analysis and Specification • Analyze the problem (making sure that you understand it), and specify the problem requirements clearly and unambiguously. • Describe exactly what the program will do, without worrying about how it will do it. Step 2: Design • Determine the necessary algorithms (and possibly other aspects of the program) and sketch out a design for them. • This is where we figure out how the program will solve the problem. • Algorithms are often designed using pseudocode. • more informal than an actual programming language • allows us to avoid worrying about the syntax of the language • example for our change-adder problem: get the number of quarters get the number of dimes get the number of nickels get the number of pennies compute the total value of the coins output the total value Step 3: Implementation • Translate your design into the programming language. pseudocode code • We need to learn more Java before we can do this! • Here's a portion or fragment of a Java program for computing the value of a particular collection of coins: quarters = 10; dimes = 3; nickels = 7; pennies = 6; cents = 25*quarters + 10*dimes + 5*nickels + pennies; System.out.println("Your total in cents is:"); System.out.println(cents); • In a moment, we'll use this fragment to examine some of the fundamental building blocks of a Java program.
    [Show full text]
  • Operator Overloading, Friend Functions/Classes
    Chapter 8 Operator Overloading, Friends, and References Learning Objectives Basic Operator Overloading Unary operators As member functions Friends and Automatic Type Conversion Friend functions, friend classes Constructors for automatic type conversion References and More Overloading << and >> Operators: = , ++, -- Operator Overloading Introduction Operators +, -, %, ==, etc. Really just functions! Simply ‘called’ with different syntax: x + 7 ‘+’ is binary operator with x & 7 as operands We ‘like’ this notation as humans Think of it as: +(x, 7) ‘+’ is the function name x, 7 are the arguments Function ‘+’ returns ‘sum’ of it’s arguments Operator Overloading Perspective Built-in operators e.g.: +, -, = , %, ==, /, * Already work for C++ built-in types In standard ‘binary’ notation We can overload them! To work with OUR types! To add ‘Chair types’, or ‘Money types’ As appropriate for our needs In ‘notation’ we’re comfortable with Always overload with similar ‘actions’! Overloading Basics Overloading operators VERY similar to overloading functions Operator itself is ‘name’ of function Example Declaration: const Money operator +( const Money& amount1, const Money& amount2); Overloads + for operands of type Money Uses constant reference parameters for efficiency Returned value is type Money Allows addition of ‘Money’ objects Overloaded ‘+’ Given previous example: Note: overloaded ‘+’ NOT member function Definition is ‘more involved’ than simple ‘add’ Requires issues of money type addition Must handle
    [Show full text]
  • Type Conversion Type Conversion
    1.3b Type Conversion Type Conversion When we write expressions involved data that involves two different data types , such as multiplying an integer and floating – point number, we need to perform a type conversion…. Two type of conversions mainly Implicit type conversion Explicit type conversion Implicit Type Conversion When the types of the two operands in a binary expression are different,C automatically converts one type to another which is known as Implicit Type Conversion. Some of the simple conversions are : Conversion Rank Conversions in Assignment Expressions Promotion Demotion Conversion in other Binary Expressions Conversion Rank In C , we assign a rank to the integral and floating point arithmetic types Real 9.long double 10.double 11.float Conversion Rank Integer 6.long long 5.long 4. int 3. short Character 2. Char Boolean 1. Bool Conversions in Assignment Expressions A simple assignment involves an assignment operator and two operands Depending on the difference in the rank, C tries to either promote or demote the right expression to make it the same rank as the left variable. Promotion occurs if the right expression has lower rank Demotion occurs if the right expression has a higher rank Promotion The rank of the left expression is elevated to the rank of the left variable The value of the expression is the value of the right expression after the promotion bool b = true; char c = ‘A’; int i = 1234; long double d = 3458.0004 c = b; //Value of c is SOH i = c; //Value of i is 65 d = b; //Value of d is 1.0 d = i; //Value of d is 1234.0 Demotion If the size of the variable at the left side can accommodate the value of the expression, there is no problem An integral or real value can be assigned to a Boolean Type.
    [Show full text]
  • Chapter 6 Data Types
    Chapter 6 Data Types • Introduction • Type Nomenclature • Primitive Types • Type constructors – Ordinal Types – Structured Types • Type Checking • Type conversion CSCI325 Chapter 6 Dr Ahmed Rafea 1 Introduction Evolution of Data Types: FORTRAN I (1956) - INTEGER, REAL, arrays … Ada (1983) - User can create a unique type for every category of variables in the problem space and have the system enforce the types Def: A descriptor is the collection of the attributes of a variable Def: A data type is a set of values, together with a set of operations on those values having certain properties CSCI325 Chapter 6 Dr Ahmed Rafea 2 Type Nomenclature C Types Basic Derived Void Numeric Pointer Array Function struct union Integral Floating Float (signed) enum Double (unsigned) Long double char Int Short int Long int CSCI325 Chapter 6 Dr Ahmed Rafea 3 Primitive Data Types Integer - 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 Floating Point - Model real numbers, but only as approximations - Languages for scientific use support at least two floating-point types; sometimes more - Usually exactly like the hardware, but not always; Decimal - For business applications (money) - Store a fixed number of decimal digits (coded) - Advantage: accuracy - Disadvantages: limited range, wastes memory Boolean - Could be implemented as bits, but often as bytes - Advantage: readability CSCI325 Chapter 6 Dr Ahmed Rafea 4 Ordinal Types (user defined) An ordinal type is one in which the range of possible values can be easily associated with the set of positive integers 1.
    [Show full text]