DOCSLIB.ORG

Presentation on Ocaml Internals

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Presentation on Ocaml Internals OCaml Internals Implementation of an ML descendant Theophile Ranquet Ecole Pour l’Informatique et les Techniques Avancées SRS 2014 [email protected] November 14, 2013 2 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 3 of 113 Variants A tagged union (also called variant, disjoint union, sum type, or algebraic data type) holds a value which may be one of several types, but only one at a time. This is very similar to the logical disjunction, in intuitionistic logic (by the Curry-Howard correspondance). 4 of 113 Variants are very convenient to represent data structures, and implement algorithms on these : 1 d a t a t y p e tree= Leaf 2 | Node of(int ∗ t r e e ∗ t r e e) 3 4 Node(5, Node(1,Leaf,Leaf), Node(3, Leaf, Node(4, Leaf, Leaf))) 5 1 3 4 1 fun countNodes(Leaf)=0 2 | countNodes(Node(int,left,right)) = 3 1 + countNodes(left)+ countNodes(right) 5 of 113 1 t y p e basic_color= 2 | Black| Red| Green| Yellow 3 | Blue| Magenta| Cyan| White 4 t y p e weight= Regular| Bold 5 t y p e color= 6 | Basic of basic_color ∗ w e i g h t 7 | RGB of int ∗ i n t ∗ i n t 8 | Gray of int 9 1 l e t color_to_int= function 2 | Basic(basic_color,weight) −> 3 l e t base= match weight with Bold −> 8 | Regular −> 0 in 4 base+ basic_color_to_int basic_color 5 | RGB(r,g,b) −> 16 +b+g ∗ 6 +r ∗ 36 6 | Grayi −> 232 +i 7 6 of 113 The limit of variants Say we want to handle a color representation with an alpha channel, but just for color_to_int (this implies we do not want to redefine our color type, this would be a hassle elsewhere). 1 t y p e extended_color= 2 | Basic of basic_color ∗ w e i g h t 3 | RGB of int ∗ i n t ∗ i n t 4 | Gray of int 5 | RGBA of int ∗ i n t ∗ i n t ∗ i n t 6 7 l e t extended_color_to_int= function 8 | RGBA(r,g,b,a) −> 256 +a+b ∗ 6 +g ∗ 36 +r ∗ 216 9 | (Basic_| RGB_| Gray_) as color −> color_to_int color 10 (∗ C h a r a c t e r s 154 −159: 11 E r r o r: This expression has type extended_color 12 but an expression was expected of type color ∗) 13 7 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 8 of 113 Polymorphic variants Polymorphic variants are more flexible and syntactically more lightweight than ordinary variants, but that extra power comes at a cost. Syntactically, polymorphic variants are distinguished from ordinary variants by the leading backtick. And unlike ordinary variants, polymorphic variants can be used without an explicit type declaration : 1 l e t three=‘Int3 2 (∗ v a l three: [>‘Int of int]=‘Int3 ∗) 3 4 l e t li=[‘ On;‘Off] 5 (∗ v a l li: [>‘Off|‘On] list=[‘ On;‘Off] ∗) 9 of 113 [< and [> The > at the beginning of the variant types is critical because it marks the types as being open to combination with other variant types. We can read the type [> ‘On | ‘Off ] as describing a variant whose tags include ‘On and ‘Off, but may include more tags as well. In other words, you can roughly translate > to mean : "these tags or more." 1 ‘Unknown:: li 2 (∗− : [>‘Off|‘On|‘Unknown] list =[‘Unknown;‘On;‘Off] ∗) 3 4 l e tf= function‘A|‘B −> ( ) 5 (∗ v a lf: [<‘A|‘B] −> unit=<fun> ∗) 6 7 l e tg= function‘A|‘B|_ −> ( ) 8 (∗ v a lf: [>‘A|‘B] −> unit=<fun> ∗) 10 of 113 Extending types 1 l e tf= function‘A −> ‘C|‘B −> ‘D|x −>x 2 (∗ v a lf: ([>‘A|‘B|‘C|‘D] as’a) −>’a=<fun> ∗) 3 4 f‘E 5 (∗− : [>‘A|‘B|‘C|‘D|‘E]=‘E ∗) 6 7 f 8 (∗ v a lf: ([>‘A|‘B|‘C|‘D] as’a) −>’a=<fun> ∗) 9 11 of 113 Abbreviations Beware of the similarity : 1 t y p e ab=A|B 2 3 t y p e ab=[‘A|‘B] 1 l e tf(x:ab) = matchx withv −>v 2 (∗ v a lf: ab −> ab=<fun> ∗) 3 4 f‘A 5 (∗− : ab=‘A ∗) 6 7 f‘C 8 (∗ E r r o r: This expression has type [>‘C] 9 but an expression was expected of type ab 10 The second variant type does not allow tag(s)‘C ∗) 12 of 113 Abbreviations Useful shorthand : 1 l e tf= function‘C −> 1 | #ab −> 0 2 (∗ v a lf: [<‘A|‘B|‘C] −> int=<fun> ∗) 3 4 f‘A 5 (∗− : int=0 ∗) 6 7 f‘C 8 (∗− : int=1 ∗) 9 10 f‘D 11 (∗ E r r o r: This expression has type [>‘D] 12 but an expression was expected of type [<‘A|‘B|‘C] 13 The second variant type does not allow tag(s)‘D ∗) 14 13 of 113 The solution to our color problem 1 l e t extended_color_to_int= function 2 | ‘RGBA(r,g,b,a) −> 256 +a+b ∗ 6 +g ∗ 36 +r ∗ 216 3 | ( ‘Basic_|‘RGB_|‘Gray_) as color −> color_to_int c o l o r 4 5 (∗ v a l extended_color_to_int: 6 [<‘Basic of 7 [<‘Black 8 |‘Blue 9 |‘Cyan 10 |‘Green 11 |‘Magenta 12 |‘Red 13 |‘White 14 |‘Yellow] ∗ 15 [<‘Bold|‘Regular] 16 |‘Gray of int 17 |‘RGB of int ∗ i n t ∗ i n t 18 |‘RGBA of int ∗ i n t ∗ i n t ∗ i n t] −> 19 i n t=<fun> ∗) 14 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 15 of 113 Subtype polymorphism In programming language theory, subtyping (also subtype polymorphism or inclusion polymorphism) is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program elements, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype. 16 of 113 Subtypes 17 of 113 Subtype polymorphism (ctd.) In object-oriented programming the term ‘polymorphism’ is commonly used to refer solely to this subtype polymorphism, while the techniques of parametric polymorphism would be considered generic programming. In the branch of mathematical logic known as type theory, System F< :, pronounced "F-sub", is an extension of system F with subtyping. System F< : has been of central importance to programming language theory since the 1980s because the core of functional programming languages, like those in the ML family, support both parametric polymorphism and record subtyping, which can be expressed in System F< :. 18 of 113 Example : in Object Oriented Programming 1 t y p e farm= quadrupede list 2 3 l e t li: farm= new cat:: new dog::[] 4 (∗ E r r o r: This expression has type cat but an expression was e x p e c t e d of type quadrupede ∗) Unlike other languages, cat and dog being both derived from the quadrupede class isn’t enough to treat them both as quadrupedes. One must use an explicit coercion : 1 l e tx :> quadrupede= new cat 2 (∗ v a lx: quadrupede=<obj> ∗) 3 4 l e t li: farm=(new cat :> quadrupede)::(new dog :> quadrupede)::[] in 5 L i s t.iter(func −> print_endline(c#species())) li 19 of 113 Coercion on variants 1 l e tfx=(x:[‘A]:> [‘A|‘B]) 2 (∗ v a lf:[‘A] −>[‘A|‘B]=<fun> ∗) 3 4 funx −> (x :> [‘A|‘B|‘C]) 5 (∗− : [<‘A|‘B|‘C] −>[‘A|‘B|‘C]=<fun> ∗) On tuples : 1 l e tfx=(x:[‘A] ∗ [‘B]:>[ ‘A|‘C] ∗ [‘B|‘D]) 2 (∗ v a lf:[‘A] ∗ [‘B] −>[‘A|‘C] ∗ [‘B|‘D]=<fun > ∗) On arrow types : 1 l e tfx=(x:[‘A|‘B] −> [ ‘C]:>[ ‘A] −> [ ‘C|‘D]) 2 (∗ v a lf:([‘A|‘B] −>[‘C]) −>[‘A] −>[‘C|‘D]= <fun> ∗) 20 of 113 Variance : covariance and contravariance 21 of 113 Variance annotations : +a and -a A somewhat obscure corner of the language. For types in OCaml like tuple and arrow, one can use + and -, called "variance annotations", to state the essence of the subtyping rule for the type – namely the direction of subtyping needed on the component types in order to deduce subtyping on the compound type. 1 t y p e (+’a, +’b)t=’a ∗ ’b 2 (∗ t y p e(’a,’b)t=’a ∗ ’b ∗) 3 4 t y p e (+’a, +’b)t=’a −> ’b 5 (∗ E r r o r: In this definition, expected parameter variances are 6 not satisfied. The1st type parameter was expected 7 to be covariant, but it is injective contravariant. ∗) 8 9 t y p e( −’a, +’b)= ’a −> ’b 10 (∗ t y p e(’a,’b)t=’a −>’b ∗) 22 of 113 Variance annotations : +a and -a (ctd.) 1 moduleM: sig 2 t y p e(’a,’b)t 3 end= struct 4 t y p e(’a,’b)t=’a ∗ ’b 5 end 6 7 l e tfx=(x:([‘A],[‘B])M.t 8 :> ( [ ‘A|‘C],[‘B|‘D])M.t) 9 (∗ E r r o r: Type([‘A],[‘B])M.t is nota subtype of 10 ([‘A|‘C],[‘B|‘D])M.t 11 The first variant type does not allow tag(s)‘C ∗) 23 of 113 Variance annotations : +a and -a (ctd.) 1 moduleM: sig 2 t y p e (+’a, +’b)t 3 end= struct 4 t y p e(’a,’b)t=’a ∗ ’b 5 end 6 7 l e tfx=(x:([‘A],[‘B])M.t 8 :> ( [ ‘A|‘C],[‘B|‘D])M.t) 9 (∗ Ok ∗) 24 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 25 of 113 Compilers 26 of 113 The OCaml toolchain Source code Lambda | /\ | parsing and preprocessing / \ closure conversion, | / \ inlining, uncurrying, | camlp4 syntax extensions v \ data representation | Bytecode \ strategy v | +----+ Parsetree (untyped AST) | Cmm | |ocamlrun | | type inference and checking | | code generation v | | assembly and Typedtree (type-annotated AST) | | linking | v v | pattern-matching compilation Interpreted Compiled | elimination of modules and classes v Lambda 27 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 28 of 113 Value representation In a running OCaml program, a value is either an "integer-like thing" or a pointer to a block.
Load more

Recommended publications
  • Mod Perl 2.0 Source Code Explained 1 Mod Perl 2.0 Source Code Explained
    mod_perl 2.0 Source Code Explained 1 mod_perl 2.0 Source Code Explained 1 mod_perl 2.0 Source Code Explained 15 Feb 2014 1 1.1 Description 1.1 Description This document explains how to navigate the mod_perl source code, modify and rebuild the existing code and most important: how to add new functionality. 1.2 Project’s Filesystem Layout In its pristine state the project is comprised of the following directories and files residing at the root direc- tory of the project: Apache-Test/ - test kit for mod_perl and Apache2::* modules ModPerl-Registry/ - ModPerl::Registry sub-project build/ - utilities used during project build docs/ - documentation lib/ - Perl modules src/ - C code that builds libmodperl.so t/ - mod_perl tests todo/ - things to be done util/ - useful utilities for developers xs/ - source xs code and maps Changes - Changes file LICENSE - ASF LICENSE document Makefile.PL - generates all the needed Makefiles After building the project, the following root directories and files get generated: Makefile - Makefile WrapXS/ - autogenerated XS code blib/ - ready to install version of the package 1.3 Directory src 1.3.1 Directory src/modules/perl/ The directory src/modules/perl includes the C source files needed to build the libmodperl library. Notice that several files in this directory are autogenerated during the perl Makefile stage. When adding new source files to this directory you should add their names to the @c_src_names vari- able in lib/ModPerl/Code.pm, so they will be picked up by the autogenerated Makefile. 1.4 Directory xs/ Apache2/ - Apache specific XS code APR/ - APR specific XS code ModPerl/ - ModPerl specific XS code maps/ - tables/ - Makefile.PL - 2 15 Feb 2014 mod_perl 2.0 Source Code Explained 1.4.1 xs/Apache2, xs/APR and xs/ModPerl modperl_xs_sv_convert.h - modperl_xs_typedefs.h - modperl_xs_util.h - typemap - 1.4.1 xs/Apache2, xs/APR and xs/ModPerl The xs/Apache2, xs/APR and xs/ModPerl directories include .h files which have C and XS code in them.
    [Show full text]
  • Typedef in C
    CC -- TTYYPPEEDDEEFF http://www.tutorialspoint.com/cprogramming/c_typedef.htm Copyright © tutorialspoint.com The C programming language provides a keyword called typedef, which you can use to give a type a new name. Following is an example to define a term BYTE for one-byte numbers: typedef unsigned char BYTE; After this type definitions, the identifier BYTE can be used as an abbreviation for the type unsigned char, for example:. BYTE b1, b2; By convention, uppercase letters are used for these definitions to remind the user that the type name is really a symbolic abbreviation, but you can use lowercase, as follows: typedef unsigned char byte; You can use typedef to give a name to user defined data type as well. For example you can use typedef with structure to define a new data type and then use that data type to define structure variables directly as follows: #include <stdio.h> #include <string.h> typedef struct Books { char title[50]; char author[50]; char subject[100]; int book_id; } Book; int main( ) { Book book; strcpy( book.title, "C Programming"); strcpy( book.author, "Nuha Ali"); strcpy( book.subject, "C Programming Tutorial"); book.book_id = 6495407; printf( "Book title : %s\n", book.title); printf( "Book author : %s\n", book.author); printf( "Book subject : %s\n", book.subject); printf( "Book book_id : %d\n", book.book_id); return 0; } When the above code is compiled and executed, it produces the following result: Book title : C Programming Book author : Nuha Ali Book subject : C Programming Tutorial Book book_id : 6495407 typedef vs #define The #define is a C-directive which is also used to define the aliases for various data types similar to typedef but with following differences: The typedef is limited to giving symbolic names to types only where as #define can be used to define alias for values as well, like you can define 1 as ONE etc.
    [Show full text]
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • REFPERSYS High-Level Goals and Design Ideas*
    REFPERSYS high-level goals and design ideas* Basile STARYNKEVITCH† Abhishek CHAKRAVARTI‡ Nimesh NEEMA§ refpersys.org October 2019 - May 2021 Abstract REFPERSYS is a REFlexive and orthogonally PERsistent SYStem (as a GPLv3+ licensed free software1) running on Linux; it is a hobby2 but serious research project for many years, mostly aimed to experiment open science ideas close to Artificial General Intelligence3 dreams, and we don’t expect use- ful or interesting results before several years of hard work. audience : LINUX free software developers4 and computer scientists interested in an experimental open science approach to reflexive systems, orthogonal persistence, symbolic artificial intelligence, knowledge engines, etc.... Nota Bene: this report contains many hyperlinks to relevant sources so its PDF should rather be read on a computer screen, e.g. with evince. Since it describes a circular design (with many cycles [Hofstadter:1979:GEB]), we recommend to read it twice (skipping footnotes and references on the first read). This entire document is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. *This document has git commit fb17387fbbb7e200, was Lua-LATEX generated on 2021-May-17 18:55 MEST, see gitlab.com/bstarynk/refpersys/ and its doc/design-ideas subdirectory. Its draft is downloadable, as a PDF file, from starynkevitch.net/Basile/refpersys-design.pdf ... †See starynkevitch.net/Basile/ and contact [email protected], 92340 Bourg La Reine (near Paris), France. ‡[email protected], FL 3C, 62B PGH Shah Road, Kolkata 700032, India.
    [Show full text]
  • Spindle Documentation Release 2.0.0
    spindle Documentation Release 2.0.0 Jorge Ortiz, Jason Liszka June 08, 2016 Contents 1 Thrift 3 1.1 Data model................................................3 1.2 Interface definition language (IDL)...................................4 1.3 Serialization formats...........................................4 2 Records 5 2.1 Creating a record.............................................5 2.2 Reading/writing records.........................................6 2.3 Record interface methods........................................6 2.4 Other methods..............................................7 2.5 Mutable trait...............................................7 2.6 Raw class.................................................7 2.7 Priming..................................................7 2.8 Proxies..................................................8 2.9 Reflection.................................................8 2.10 Field descriptors.............................................8 3 Custom types 9 3.1 Enhanced types..............................................9 3.2 Bitfields..................................................9 3.3 Type-safe IDs............................................... 10 4 Enums 13 4.1 Enum value methods........................................... 13 4.2 Companion object methods....................................... 13 4.3 Matching and unknown values...................................... 14 4.4 Serializing to string............................................ 14 4.5 Examples................................................. 14 5 Working
    [Show full text]
  • Multi-Level Constraints
    Multi-Level Constraints Tony Clark1 and Ulrich Frank2 1 Aston University, UK, [email protected] 2 University of Duisburg-Essen, DE, [email protected] Abstract. Meta-modelling and domain-specific modelling languages are supported by multi-level modelling which liberates model-based engi- neering from the traditional two-level type-instance language architec- ture. Proponents of this approach claim that multi-level modelling in- creases the quality of the resulting systems by introducing a second ab- straction dimension and thereby allowing both intra-level abstraction via sub-typing and inter-level abstraction via meta-types. Modelling ap- proaches include constraint languages that are used to express model semantics. Traditional languages, such as OCL, support intra-level con- straints, but not inter-level constraints. This paper motivates the need for multi-level constraints, shows how to implement such a language in a reflexive language architecture and applies multi-level constraints to an example multi-level model. 1 Introduction Conceptual models aim to bridge the gap between natural languages that are required to design and use a system and implementation languages. To this end, general-purpose modelling languages (GPML) like the UML consist of concepts that represent semantic primitives such as class, attribute, etc., that, on the one hand correspond to concepts of foundational ontologies, e.g., [4], and on the other hand can be nicely mapped to corresponding elements of object-oriented programming languages. Since GPML can be used to model a wide range of systems, they promise at- tractive economies of scale. At the same time, their use suffers from the fact that they offer generic concepts only.
    [Show full text]
  • Union Types for Semistructured Data
    Edinburgh Research Explorer Union Types for Semistructured Data Citation for published version: Buneman, P & Pierce, B 1999, Union Types for Semistructured Data. in Union Types for Semistructured Data: 7th International Workshop on Database Programming Languages, DBPL’99 Kinloch Rannoch, UK, September 1–3,1999 Revised Papers. Lecture Notes in Computer Science, vol. 1949, Springer-Verlag GmbH, pp. 184-207. https://doi.org/10.1007/3-540-44543-9_12 Digital Object Identifier (DOI): 10.1007/3-540-44543-9_12 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Union Types for Semistructured Data General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 27. Sep. 2021 Union Typ es for Semistructured Data Peter Buneman Benjamin Pierce University of Pennsylvania Dept of Computer Information Science South rd Street Philadelphia PA USA fpeterbcpiercegcisupenn edu Technical
    [Show full text]
  • Enum, Typedef, Structures and Unions CS 2022: Introduction to C
    Enum, Typedef, Structures and Unions CS 2022: Introduction to C Instructor: Hussam Abu-Libdeh Cornell University (based on slides by Saikat Guha) Fall 2009, Lecture 6 Enum, Typedef, Structures and Unions CS 2022, Fall 2009, Lecture 6 Numerical Types I int: machine-dependent I Standard integers I defined in stdint.h (#include <stdint.h>) I int8 t: 8-bits signed I int16 t: 16-bits signed I int32 t: 32-bits signed I int64 t: 64-bits signed I uint8 t, uint32 t, ...: unsigned I Floating point numbers I float: 32-bits I double: 64-bits Enum, Typedef, Structures and Unions CS 2022, Fall 2009, Lecture 6 Complex Types I Enumerations (user-defined weekday: sunday, monday, ...) I Structures (user-defined combinations of other types) I Unions (same data, multiple interpretations) I Function pointers I Arrays and Pointers of the above Enum, Typedef, Structures and Unions CS 2022, Fall 2009, Lecture 6 Enumerations enum days {mon, tue, wed, thu, fri, sat, sun}; // Same as: // #define mon 0 // #define tue 1 // ... // #define sun 6 enum days {mon=3, tue=8, wed, thu, fri, sat, sun}; // Same as: // #define mon 3 // #define tue 8 // ... // #define sun 13 Enum, Typedef, Structures and Unions CS 2022, Fall 2009, Lecture 6 Enumerations enum days day; // Same as: int day; for(day = mon; day <= sun; day++) { if (day == sun) { printf("Sun\n"); } else { printf("day = %d\n", day); } } Enum, Typedef, Structures and Unions CS 2022, Fall 2009, Lecture 6 Enumerations I Basically integers I Can use in expressions like ints I Makes code easier to read I Cannot get string equiv.
    [Show full text]
  • Programming the Capabilities of the PC Have Changed Greatly Since the Introduction of Electronic Computers
    1 www.onlineeducation.bharatsevaksamaj.net www.bssskillmission.in INTRODUCTION TO PROGRAMMING LANGUAGE Topic Objective: At the end of this topic the student will be able to understand: History of Computer Programming C++ Definition/Overview: Overview: A personal computer (PC) is any general-purpose computer whose original sales price, size, and capabilities make it useful for individuals, and which is intended to be operated directly by an end user, with no intervening computer operator. Today a PC may be a desktop computer, a laptop computer or a tablet computer. The most common operating systems are Microsoft Windows, Mac OS X and Linux, while the most common microprocessors are x86-compatible CPUs, ARM architecture CPUs and PowerPC CPUs. Software applications for personal computers include word processing, spreadsheets, databases, games, and myriad of personal productivity and special-purpose software. Modern personal computers often have high-speed or dial-up connections to the Internet, allowing access to the World Wide Web and a wide range of other resources. Key Points: 1. History of ComputeWWW.BSSVE.INr Programming The capabilities of the PC have changed greatly since the introduction of electronic computers. By the early 1970s, people in academic or research institutions had the opportunity for single-person use of a computer system in interactive mode for extended durations, although these systems would still have been too expensive to be owned by a single person. The introduction of the microprocessor, a single chip with all the circuitry that formerly occupied large cabinets, led to the proliferation of personal computers after about 1975. Early personal computers - generally called microcomputers - were sold often in Electronic kit form and in limited volumes, and were of interest mostly to hobbyists and technicians.
    [Show full text]
  • Certification of a Tool Chain for Deductive Program Verification Paolo Herms
    Certification of a Tool Chain for Deductive Program Verification Paolo Herms To cite this version: Paolo Herms. Certification of a Tool Chain for Deductive Program Verification. Other [cs.OH]. Université Paris Sud - Paris XI, 2013. English. NNT : 2013PA112006. tel-00789543 HAL Id: tel-00789543 https://tel.archives-ouvertes.fr/tel-00789543 Submitted on 18 Feb 2013 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. UNIVERSITÉ DE PARIS-SUD École doctorale d’Informatique THÈSE présentée pour obtenir le Grade de Docteur en Sciences de l’Université Paris-Sud Discipline : Informatique PAR Paolo HERMS −! − SUJET : Certification of a Tool Chain for Deductive Program Verification soutenue le 14 janvier 2013 devant la commission d’examen MM. Roberto Di Cosmo Président du Jury Xavier Leroy Rapporteur Gilles Barthe Rapporteur Emmanuel Ledinot Examinateur Burkhart Wolff Examinateur Claude Marché Directeur de Thèse Benjamin Monate Co-directeur de Thèse Jean-François Monin Invité Résumé Cette thèse s’inscrit dans le domaine de la vérification du logiciel. Le but de la vérification du logiciel est d’assurer qu’une implémentation, un programme, répond aux exigences, satis- fait sa spécification. Cela est particulièrement important pour le logiciel critique, tel que des systèmes de contrôle d’avions, trains ou centrales électriques, où un mauvais fonctionnement pendant l’opération aurait des conséquences catastrophiques.
    [Show full text]
  • Djangoshop Release 0.11.2
    djangoSHOP Release 0.11.2 Oct 27, 2017 Contents 1 Software Architecture 1 2 Unique Features of django-SHOP5 3 Upgrading 7 4 Tutorial 9 5 Reference 33 6 How To’s 125 7 Development and Community 131 8 To be written 149 9 License 155 Python Module Index 157 i ii CHAPTER 1 Software Architecture The django-SHOP framework is, as its name implies, a framework and not a software which runs out of the box. Instead, an e-commerce site built upon django-SHOP, always consists of this framework, a bunch of other Django apps and the merchant’s own implementation. While this may seem more complicate than a ready-to-use solution, it gives the programmer enormous advantages during the implementation: Not everything can be “explained” to a software system using graphical user interfaces. After reaching a certain point of complexity, it normally is easier to pour those requirements into executable code, rather than to expect yet another set of configuration buttons. When evaluating django-SHOP with other e-commerce solutions, I therefore suggest to do the following litmus test: Consider a product which shall be sold world-wide. Depending on the country’s origin of the request, use the native language and the local currency. Due to export restrictions, some products can not be sold everywhere. Moreover, in some countries the value added tax is part of the product’s price, and must be stated separately on the invoice, while in other countries, products are advertised using net prices, and tax is added later on the invoice.
    [Show full text]
  • Evaluation of On-Ramp Control Algorithms
    CALIFORNIA PATH PROGRAM INSTITUTE OF TRANSPORTATION STUDIES UNIVERSITY OF CALIFORNIA, BERKELEY Evaluation of On-ramp Control Algorithms Michael Zhang, Taewan Kim, Xiaojian Nie, Wenlong Jin University of California, Davis Lianyu Chu, Will Recker University of California, Irvine California PATH Research Report UCB-ITS-PRR-2001-36 This work was performed as part of the California PATH Program of the University of California, in cooperation with the State of California Business, Transportation, and Housing Agency, Department of Transportation; and the United States Department of Transportation, Federal Highway Administration. The contents of this report reflect the views of the authors who are responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the State of California. This report does not constitute a standard, specification, or regulation. Final Report for MOU 3013 December 2001 ISSN 1055-1425 CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS Evaluation of On-ramp Control Algorithms September 2001 Michael Zhang, Taewan Kim, Xiaojian Nie, Wenlong Jin University of California at Davis Lianyu Chu, Will Recker PATH Center for ATMS Research University of California, Irvine Institute of Transportation Studies One Shields Avenue University of California, Davis Davis, CA 95616 ACKNOWLEDGEMENTS Technical assistance on Paramics simulation from the Quadstone Technical Support sta is also gratefully acknowledged. ii EXECUTIVE SUMMARY This project has three objectives: 1) review existing ramp metering algorithms and choose a few attractive ones for further evaluation, 2) develop a ramp metering evaluation framework using microscopic simulation, and 3) compare the performances of the selected algorithms and make recommendations about future developments and eld tests of ramp metering systems.
    [Show full text]