DOCSLIB.ORG

Pubtex Output 2001.04.27:1405

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Pubtex Output 2001.04.27:1405 SAS/C® Library Reference, Volume 2, Release 7.00 The correct bibliographic citation for this manual is as follows: SAS Institute Inc., SAS/C Library Reference, Volume 2, Release 7.00, Cary, NC: SAS Institute Inc., 2001. SAS/C Library Reference, Volume 2, Release 7.00 Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved. 1–58025–733–X All rights reserved. Produced in the United States of America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, by any form or by any means, electronic, mechanical, photocopying, or otherwise, without the prior written permission of the publisher, SAS Institute, Inc. U.S. Government Restricted Rights Notice. Use, duplication, or disclosure of this software and related documentation by the U.S. government is subject to the Agreement with SAS Institute and the restrictions set forth in FAR 52.227–19 Commercial Computer Software-Restricted Rights (June 1987). SAS Institute Inc., SAS Campus Drive, Cary, North Carolina 27513. 1st printing, April 2001 SAS Publishing provides a complete selection of books and electronic products to help customers use SAS software to its fullest potential. For more information about our e-books, CD-ROM, hard copy books, and Web-based training, visit the SAS Publishing Web site at www.sas.com/pubs or call 1-800-727–3228. SAS® and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. IBM® and all other International Business Machines Corporation product or service names are registered trademarks or trademarks of International Business Machines Corporation in the USA and other countries. Other brand and product names are registered trademarks or trademarks of their respective companies. Contents PART1 Special Features of the SAS/C Library 1 Chapter 1 R Dynamic-Loading Functions 3 Introduction 3 Function Descriptions 4 Chapter 2 R CMS Low-Level I/O Functions 19 Introduction 19 Related Utility Functions 26 Chapter 3 R MVS Low-Level I/O Functions 29 Introduction 29 DCBs and DCB Exit Routines 30 The Record-Oriented BSAM Interface 36 Chapter 4 R OS/390 Multitasking and Other Low-Level System Interfaces 71 Introduction 71 Multitasking SAS/C Applications 71 Compatibility Changes 72 Function Descriptions 73 Chapter 5 R Inter-User Communications Vehicle (IUCV) Functions 103 Introduction 103 IUCV Communications Overview 103 IUCV, Signal Handling, and Message Processing 105 IUCV Parameter Lists and External Interrupt Data Formats 107 Message Queues 109 Return Codes 109 Function Descriptions 110 An Example of IUCV Communication 116 Guidelines and Cautions 122 Chapter 6 R APPC/VM Functions 123 Introduction 123 APPC/VM Parameter Lists and External Interrupt Data Formats 124 Function Descriptions 126 APPC/VM Communication Example Programs 129 Guidelines and Cautions 138 Chapter 7 R The Subcommand Interface to EXECs and CLISTs 139 Introduction 139 Subcommand Processing in C Programs 139 iv Overview of the SUBCOM Environment 141 Function Descriptions 144 Examples of SUBCOM Processing 159 Guidelines for Subcommand Processing 165 Chapter 8 R The CMS REXX SAS/C Interface 167 Introduction 167 REXX Concepts and Background 167 How the Library Interfaces with REXX 169 Function Descriptions 172 An Example of a REXX Function Package 181 Additional Guidelines and Related Topics 183 Chapter 9 R Coprocessing Functions 185 Introduction 185 cocall and coreturn 186 Coprocess States 187 Passing Data between Coprocesses 188 Coprocess Data Types and Constants 189 Coprocess Identifiers 190 Restrictions 190 A Coprocessing Example 190 Advanced Topics: Program Termination 193 Advanced Topics: Signal Handling 194 Function Descriptions 195 Chapter 10 R Localization 207 Introduction 207 Locales and Categories 208 The "S370" Locale 210 The "POSIX" Locale 210 Library-Supplied Locales 211 Function Descriptions 212 User-Added Locales 221 Chapter 11 R Multibyte Character Functions 235 Introduction 235 SAS/C Implementation of Multibyte Character Sequences 235 Locales and Multibyte Character Sequences 238 Function Descriptions 238 Chapter 12 R User-Added Signals 247 Introduction 247 Notes on Handlers for User-Defined Signals 248 Restrictions on Synchronous and Asynchronous Signals 248 Summary of Routines for Adding Signals 248 SAS/C Library Routines for Adding New Signals 254 v Chapter 13 R Getting Environmental Information 257 Introduction 257 The L$UENVR Routine 257 Function Descriptions 259 PART2 SAS/C Socket Library for TCP/IP 265 Chapter 14 R The TCP/IP Protocol Suite 267 Overview of TCP/IP 267 Internet Protocol (IP) 268 User Datagram Protocol (UDP) 268 Transmission Control Protocol (TCP) 269 Domain Name System (DNS) 269 OS/390 and CMS TCP/IP Implementation 270 Chapter 15 R The BSD UNIX Socket Library 271 Introduction 272 Overview of the BSD UNIX Socket Library 272 Header Files 273 Socket Functions 283 Chapter 16 R Porting UNIX Socket Applications to the SAS/C Environment 289 Introduction 289 Integrated and Non-Integrated Sockets 289 Socket Library Restrictions 290 Function Names 291 Header Filenames 292 errno 292 BSD Library Dependencies 293 INETD and BSD Kernel Routine Dependencies 293 Character Sets 294 The Resolver 295 Chapter 17 R Network Administration 297 Introduction 297 Configuration Data Sets 297 Search Logic 298 Specifying TCPIP_PREFIX for OS/390 300 Specifying TCPIP_MACH 300 gethostbyname and Resolver Configuration 300 Configuring for the CMS Environment 301 Configuring for the OS/390 Environment 301 Chapter 18 R Socket Function Reference 303 Introduction 303 vi PART3 SAS/C POSIX Support 403 Chapter 19 R Introduction to POSIX 405 POSIX and UNIX System Services Concepts 405 The errno Variable 408 SAS/C USS Interfaces 410 Chapter 20 R POSIX Function Reference 419 Introduction 419 Index 623 1 PART1 Special Features of the SAS/C Library Chapter 1..........Dynamic-Loading Functions 3 Chapter 2..........CMS Low-Level I/O Functions 19 Chapter 3..........MVS Low-Level I/O Functions 29 Chapter 4..........OS/390 Multitasking and Other Low-Level System Interfaces 71 Chapter 5..........Inter-User Communications Vehicle (IUCV) Functions 103 Chapter 6..........APPC/VM Functions 123 Chapter 7..........The Subcommand Interface to EXECs and CLISTs 139 Chapter 8..........The CMS REXX SAS/C Interface 167 Chapter 9..........Coprocessing Functions 185 Chapter 10.........Localization 207 Chapter 11.........Multibyte Character Functions 235 Chapter 12.........User-Added Signals 247 Chapter 13.........Getting Environmental Information 257 2 3 CHAPTER 1 Dynamic-Loading Functions Introduction 3 Cautions 3 Dynamic Load Modules 4 Function Descriptions 4 Introduction Although most C programs are linked together as a single load module, for large applications it is often convenient to divide a program into several load modules that can be loaded into memory and unloaded independently. The SAS/C Compiler and Library support multiple load module programs, but you must develop such programs carefully. As with any C program, program execution always begins with a function named main. The load module containing the main function must remain in memory at all times. Each subordinate (dynamically loaded) load module must contain a function named _dynamn (which is a contraction for dynamic main). From the perspective of the compiler, the _dynamn function serves the same role in the subordinate load module as main serves in the module containing the main program. Cautions Note that load modules linked with the SAS/C Library are of two distinct types: main modules and dynamically loadable modules. A main module is one which contains a main function, or which can cause the C environment to be created in conjunction with using the indep compiler option. A dynamically loadable module is one which contains a _dynamn function. It is not possible to create a load module which is of both types. Any attempt to do so will fail at link time or at execution time. Two consequences of this requirement are: You cannot link a main function and a _dynamn function into the same load module. In particular, this means that you cannot have a source file which includes both these functions. You cannot create a C framework by calling a function that was compiled with the indep option into a load module which includes a _dynamn function. This restriction is imposed so that dynamically loadable modules are not forced to include the large amount of code needed to create a new C framework. 4 Dynamic Load Modules R Chapter 1 Dynamic Load Modules Load modules subordinate to the main program module can be loaded by use of the loadm and unloadm functions. The second argument to loadm is a pointer to a function pointer in which the address of the loaded _dynamn routine will be stored. In addition to loadm and unloadm, the library provides functions to load and unload modules containing only data (loadd and unloadd) and a function that converts a load module entry point address to a function pointer (buildm). Two other functions, addsrch and delsrch, are provided, primarily for CMS, to define the load module search order. The search order consists of the possible locations of dynamically loaded modules and the order in which they are processed. Before any of these routines can be used, the source program must include the header file <dynam.h> using the #include statement. Transfers of control between load modules are possible only by using function pointers. However, through the use of appropriate pointers, a routine in one load module can call a routine in any other load module. The inability of one load module to call another directly is a special case of a more general restriction; namely, load modules cannot share external variables. More precisely, two external variables (or functions) of the same name in different load modules are independent of each other. (There are a few special cases such as the variable errno, which contains the number of the most recent run-time problem.) See Appendix 4, "Sharing extern Variables among Load Modules," in the SAS/C Compiler and Library User’s Guide for additional information.
Load more

Recommended publications
  • Hardware Architectures for Software Security
    Hardware Architectures for Software Security Joshua N. Edmison Dissertation submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Dr. Mark T. Jones, Chair Dr. Lynn Abbott Dr. Peter M. Athanas Dr. Ezra Brown Dr. Thomas L. Martin Dr. Cameron D. Patterson June 29, 2006 Bradley Department of Electrical and Computer Engineering Blacksburg, Virginia Keywords: Security, architecture, FPGA, configurable, graph theory, information flow Copyright 2005 c , Joshua N. Edmison Hardware Architectures for Software Security Joshua N. Edmison (ABSTRACT) The need for hardware-based software protection stems primarily from the increasing value of software coupled with the inability to trust software that utilizes or manages shared resources. By correctly utilizing security functions in hardware, trust can be removed from software. Existing hardware-based software protection solutions generally suffer from utiliza- tion of trusted software, lack of implementation, and/or extreme measures such as processor redesign. In contrast, the research outlined in this document proposes that substantial, hardware-based software protection can be achieved, without trusting software or redesign- ing the processor, by augmenting existing processors with security management hardware placed outside of the processor boundary. Benefits of this approach include the ability to add security features to nearly any processor, update security features without redesigning the processor, and provide maximum transparency to the software development and distribution processes. The major contributions of this research include the the augmentation method- ology, design principles, and a graph-based method for analyzing hardware-based security systems.
    [Show full text]
  • SAS/C Library Reference, Third Edition, Release 6.00 Volume 2
    SAS/C Library Reference, Third Edition, Release 6.00 Volume 2 SAS Institute Inc. SAS Campus Drive Cary, NC 27513 The correct bibliographic citation for this manual is as follows: SAS Institute Inc., SAS/C Library Reference, Third Edition, Volume 2, Release 6.00, Cary, NC: SAS Institute Inc., 1995. 623 pp. SAS/C Library Reference, Third Edition, Volume 2, Release 6.00 Copyright 1995 by SAS Institute Inc., Cary, NC, USA. ISBN 1-55544-667-1 All rights reserved. Printed in the United States of America. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, or otherwise, without the prior written permission of the publisher, SAS Institute Inc. Restricted Rights Legend. Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. SAS Institute Inc., SAS Campus Drive, Cary, North Carolina 27513. 1st printing, October 1995 The SAS System is an integrated system of software providing complete control over data access, management, analysis, and presentation. Base SAS software is the foundation of the SAS System. Products within the SAS System include SAS/ACCESS, SAS/AF, SAS/ASSIST, SAS/CALC, SAS/CONNECT, SAS/CPE, SAS/DMI, SAS/EIS, SAS/ENGLISH, SAS/ETS, SAS/FSP, SAS/GRAPH, SAS/IMAGE, SAS/IML, SAS/IMS-DL/I, SAS/INSIGHT, SAS/LAB, SAS/NVISION, SAS/OR, SAS/PH-Clinical, SAS/QC, SAS/REPLAY-CICS, SAS/SESSION, SAS/SHARE, SAS/SPECTRAVIEW, SAS/STAT, SAS/TOOLKIT, SAS/TRADER, SAS/TUTOR, SAS/DB2, SAS/GEO, SAS/GIS, SAS/PH-Kinetics, SAS/SHARE*NET, and SAS/SQL-DS software.
    [Show full text]
  • Kguard: Lightweight Kernel Protection Against Return-To-User Attacks
    kGuard: Lightweight Kernel Protection against Return-to-user Attacks VasileiosP.Kemerlis GeorgiosPortokalidis AngelosD.Keromytis Network Security Lab Department of Computer Science Columbia University, New York, NY, USA {vpk, porto, angelos}@cs.columbia.edu Abstract Such return-to-user (ret2usr) attacks have affected all major OSs, including Windows [60], Linux [16, 18], Return-to-user (ret2usr) attacks exploit the operating sys- and FreeBSD [19, 59, 61], while they are not limited to tem kernel, enabling local users to hijack privileged ex- x86 systems [23], but have also targeted the ARM [30], ecution paths and execute arbitrary code with elevated DEC [31], and PowerPC [25] architectures. privileges. Current defenses have proven to be inade- There are numerous reasons to why attacks against the quate, as they have been repeatedly circumvented, in- kernel are becoming more common. First and foremost, cur considerable overhead, or rely on extended hypervi- processes running with administrative privileges have be- sors and special hardware features. We present kGuard, come harder to exploit due to the various defense mech- a compiler plugin that augments the kernel with com- anisms adopted by modern OSs [52, 34]. Second, NULL pact inline guards, which prevent ret2usr with low per- pointer dereference errors had not received significant at- formance and space overhead. kGuard can be used with tention, until recently, exactly because they were thought any operating system that features a weak separation be- impractical and too difficult to exploit. In fact, 2009 has tween kernel and user space, requires no modifications been proclaimed, by some security researchers, as “the to the OS, and is applicable to both 32- and 64-bit ar- year of the kernel NULL pointer dereference flaw”[15].
    [Show full text]
  • Scala with Explicit Nulls
    Scala with Explicit Nulls by Abel Nieto Rodriguez A thesis presented to the University of Waterloo in fulfillment of the thesis requirement for the degree of Master of Mathematics in Computer Science Waterloo, Ontario, Canada, 2019 c Abel Nieto Rodriguez 2019 Author's Declaration I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract The Scala programming language unifies the object-oriented and functional styles of programming. One common source of errors in Scala programs is null references. In this dissertation, I present a modification to the Scala type system that makes nullability explicit in the types. This allows us to turn runtime errors into compile-time errors. I have implemented this design for explicit nulls as a fork of the Dotty (Scala 3) compiler. I evaluate the design by migrating a number of Scala libraries to use explicit nulls. In the second part of the dissertation, I give a theoretical foundation for explicit nulls. I do this in two, independent ways. First, I give a denotational semantics for type nulli- fication, a key part of the explicit nulls design. Separately, I present a core calculus for null interoperability that models how languages with explicit nulls (like Scala) interact with languages where null remains implicit (like Java). Using the concept of blame from gradual typing, I show that if a well-typed program fails with certain kinds of nullability errors, an implicitly-nullable subterm can always be blamed for the failure.
    [Show full text]
  • Inside an Apple
    Singh.book Page 155 Thursday, May 25, 2006 11:46 AM CHAPTER 3 Inside an Apple pple initiated its transition from the 68K hardware platform to the PowerPC A in 1994. Within the next two years, Apple’s entire line of computers moved to the PowerPC. The various PowerPC-based Apple computer families available at any given time have often differed in system architecture,1 the specific proces- sor used, and the processor vendor. For example, before the G4 iBook was intro- duced in October 2003, Apple’s then current systems included three generations of the PowerPC: the G3, the G4, and the G5. Whereas the G4 processor line is supplied by Motorola, the G3 and the G5 are from IBM. Table 3–1 lists the vari- ous PowerPC processors2 used by Apple. On June 6, 2005, at the Worldwide Developers Conference in San Francisco, Apple announced its plans to base future models of Macintosh computers on Intel processors. The move was presented as a two-year transition: Apple stated that 1. System architecture refers to the type and interconnection of a system’s hardware components, including—but not limited to—the processor type. 2. The list does not account for minor differences between processor models—for example, differ- ences based solely on processor clock frequencies. 155 Singh.book Page 156 Thursday, May 25, 2006 11:46 AM 156 Chapter 3 Inside an Apple TABLE 3–1 Processors Used in PowerPC-Based Apple Systems Processor Introduced Discontinued PowerPC 601 March 1994 June 1996 PowerPC 603 April 1995 May 1996 PowerPC 603e April 1996 August 1998 PowerPC 604 August 1995 April 1998 PowerPC 604e August 1996 September 1998 PowerPC G3 November 1997 October 2003 PowerPC G4 October 1999 — PowerPC G5 June 2003 — PowerPC G5 (dual-core) October 2005 — although x86-based Macintosh models would become available by mid-2006, all Apple computers would transition to the x86 platform only by the end of 2007.
    [Show full text]
  • Armv6-M Architecture Reference Manual
    ARMv6-M Architecture Reference Manual Copyright © 2007-2008, 2010 ARM Limited. All rights reserved. ARM DDI 0419C (ID092410) ARMv6-M Architecture Reference Manual Copyright © 2007-2008, 2010 ARM Limited. All rights reserved. Release Information The following changes have been made to this document. Change History Date Issue Confidentiality Change March 2007 A Non-Confidential First release September 2008 B Non-Confidential, Restricted Access Additions to the System Control Block, power management support, corrections to errata and clarifications September 2010 C Non-confidential Additions to describe the Unprivileged/Privileged Extension and the Protected Memory System Architecture (PMSA) Extension. Also extensive clarification and reorganization. Proprietary Notice This ARM Architecture Reference Manual is protected by copyright and the practice or implementation of the information herein may be protected by one or more patents or pending applications. No part of this ARM Architecture Reference Manual may be reproduced in any form by any means without the express prior written permission of ARM. No license, express or implied, by estoppel or otherwise to any intellectual property rights is granted by this ARM Architecture Reference Manual. Your access to the information in this ARM Architecture Reference Manual is conditional upon your acceptance that you will not use or permit others to use the information for the purposes of determining whether implementations of the ARM architecture infringe any third party patents. This ARM Architecture Reference Manual is provided “as is”. ARM makes no representations or warranties, either express or implied, included but not limited to, warranties of merchantability, fitness for a particular purpose, or non-infringement, that the content of this ARM Architecture Reference Manual is suitable for any particular purpose or that any practice or implementation of the contents of the ARM Architecture Reference Manual will not infringe any third party patents, copyrights, trade secrets, or other rights.
    [Show full text]
  • A Pliable Hybrid Architecture for Code Isolation
    A PLIABLE HYBRID ARCHITECTURE FOR CODE ISOLATION A Dissertation Presented to The Academic Faculty by Ivan B. Ganev In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the College of Computing Georgia Institute of Technology August 2007 Copyright c 2007 by Ivan B. Ganev A PLIABLE HYBRID ARCHITECTURE FOR CODE ISOLATION Approved by: Karsten Schwan, Adviser Santosh Pande College of Computing College of Computing Georgia Institute of Technology Georgia Institute of Technology Mustaque Ahamad Kiran Panesar College of Computing Google Inc. Georgia Institute of Technology Greg Eisenhauer Date Approved: 9 April 2007 College of Computing Georgia Institute of Technology For Dana and Ginka. iii ACKNOWLEDGEMENTS For the successful completion of this work, I owe an enormous debt of gratitude to many people who have so generously given me their friendship, encouragement, and time. Perhaps too many to list individually, yet, I would be remiss not to try. Thus, in no particular order, I would like to thank: • Karsten Schwan, for giving me complete freedom to pursue my research interests and for always being so supportive, understanding, resourceful, and wise. I could not have wished for a better adviser. • Greg Eisenhauer, for sharing his technical expertise and solid foundation of code. • Kiran Panesar, Mustaque Ahamad, and Santosh Pande, for their guidance and helpful suggestions. • Ken Mackenzie, for being a source of true inspiration. • Josh Fryman, for so many enlightening discussions, ruthless paper revisions, and his contagiously positive attitude. • Craig Ulmer, for all the jokes and encouragement. • Richard West, Christian Poellabauer, Himanshu Raj, Sanjay Kumar, Balasubrama- nian Seshasayee, and countless other fellow Georgia Tech students for their time and friendship.
    [Show full text]
  • Execution Unit ISA (Ivy Bridge)
    Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM) Volume 4 Part 3: Execution Unit ISA (Ivy Bridge) For the 2012 Intel® Core™ Processor Family May 2012 Revision 1.0 NOTICE: This document contains information on products in the design phase of development, and Intel reserves the right to add or remove product features at any time, with or without changes to this open source documentation. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 Creative Commons License You are free to Share — to copy, distribute, display, and perform the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). No Derivative Works. You may not alter, transform, or build upon this work. INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or
    [Show full text]
  • (Lambda) Functions
    Real World Haskell main.title Page iii Monday, May 19, 2008 11:21 AM ?? EDITION Real World TomcatHaskell™ The Definitive Guide Bryan O'Sullivan, JasonJohn Goerzen,Brittain and and Ian Don F. DarwinStewart Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Real World Haskell by Bryan O'Sullivan, John Goerzen, and Don Stewart Copyright © 2007, 2008 Bryan O'SullivanJohn GoerzenDon Stewart. All rights reserved. Editor: Mike Loukides Printing History: ISBN: 978---059-65149-83 1220034018 Table of Contents Why functional programming? Why Haskell? .................................... xiii 1. Getting Started ......................................................... 1 Your Haskell environment 1 Getting started with ghci, the interpreter 2 Basic interaction: using ghci as a calculator 3 Command line editing in ghci 9 Lists 9 Strings and characters 11 First steps with types 12 A simple program 15 Exercises 16 2. Types and Functions .................................................... 17 Why care about types? 17 Haskell's type system 17 What to expect from the type system 20 Some common basic types 21 Function application 22 Useful composite data types: lists and tuples 23 Functions over lists and tuples 26 Function types and purity 27 Haskell source files, and writing simple functions 27 Understanding evaluation by example 32 Polymorphism in Haskell 36 The type of a function of more than one argument 38 Exercises 39 Why the fuss over purity? 39 Conclusion 40 3. Defining Types, Streamlining Functions .................................... 41 Defining a new data type 41 v Type synonyms 43 Algebraic data types 44 Pattern matching 50 Record syntax 55 Parameterised types 57 Recursive types 58 Reporting errors 60 Introducing local variables 62 The offside rule and white space in an expression 64 The case expression 67 Common beginner mistakes with patterns 67 Conditional evaluation with guards 68 Exercises 69 4.
    [Show full text]