DOCSLIB.ORG

Arxiv:1306.1870V1 [Cs.PL] 8 Jun 2013 Contents

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Cyan Language Jos´ede Oliveira Guimar~aes Campus de Sorocaba da UFSCar Sorocaba, SP Brasil [email protected] [email protected] November 10, 2018 arXiv:1306.1870v1 [cs.PL] 8 Jun 2013 Contents 1 An Overview of Cyan 6 2 Packages and File organization 40 3 Basic Elements 44 3.1 Identifiers . 44 3.2 Comments . 44 3.3 Assignments . 45 3.4 Basic Types . 46 3.5 Operator and Selector Precedence . 53 3.6 Loops, Ifs, and other Statements . 54 3.7 Arrays . 58 4 Objects 59 4.1 Constants . 64 4.2 self . 64 4.3 clone Methods . 64 4.4 Shared Variables . 65 4.5 new, init, and initOnce Methods . 65 4.6 Order of Initialization . 69 4.7 Keyword Methods and Selectors . 70 4.8 On Names and Scope . 72 4.9 Operators as Method Names . 73 4.10 Method Overloading . 74 4.11 Inheritance . 76 4.12 Multi-Methods . 78 4.13 Any, the Super-prototype of Everybody . 79 4.14 Abstract Prototypes . 85 4.15 Interfaces . 86 4.16 Types and Subtypes . 88 4.17 Mixin Inheritance . 89 4.18 Runtime Metaobjects or Dynamic Mixins . 94 5 Metaobjects 96 5.1 Pre-defined Metaobjects . 96 5.2 Syntax and Semantics . 101 5.3 Metaobject Examples . 102 5.4 Codegs . 102 1 6 Dynamic Typing 107 7 Generic Prototypes 113 8 Important Library Objects 116 8.1 System . 116 8.2 Input and Output . 116 8.3 Tuples . 117 8.4 Dynamic Tuples . 122 8.5 Unions . 123 8.6 Intervals . 125 9 Grammar Methods 128 9.1 Matching Message Sends with Methods . 130 9.2 The Type of the Parameter . 131 9.3 Unions and Optional Selectors . 133 9.4 Refining the Definition of Grammar Methods . 137 9.5 Context-Free Languages . 139 9.6 Default Parameter Value . 141 9.7 Domain Specific Languages . 143 9.8 Groovy Builders . 147 9.9 A Problem with Grammar Methods . 150 9.10 Limitations of Grammar Methods . 151 10 Blocks 153 10.1 Problems with Closures . 155 10.2 Some More Definitions . 158 10.3 Classifications of Blocks: u-Blocks and r-Blocks . 158 10.4 Type Checking Blocks . 168 10.5 Some Block Examples . 170 10.6 Why Blocks are Statically-Typed in Cyan . 171 10.7 Blocks with Multiple Selectors . 172 10.8 The Type of Methods and Methods as Objects . 173 10.9 Message Sends . 176 10.10Methods of Blocks for Decision and Repetition . 177 10.11Context Blocks . 178 10.12Implementing r-Blocks as u-Blocks . 185 11 Context Objects 187 11.1 Using Instance Variables as Parameters to Context Objects . 188 11.2 Passing Parameters by Copy . 189 11.3 What the Compiler Does With Context Objects . 190 11.4 Type Checking Context Objects . 192 11.5 Adding Context Objects to Prototypes . 194 11.6 Passing Parameters by Reference . 195 11.7 Should Context Objects be User-Defined? . 197 11.8 More Examples . 198 11.9 A New Feature for Context Objects? . 199 2 12 The Exception Handling System 202 12.1 Using Regular Objects to Treat Exceptions . 205 12.2 Selecting an eval Method for Exception Treatment . 205 12.3 Other Methods and Selectors for Exception Treatment . 209 12.4 Why Cyan Does Not Support Checked Exceptions? . 212 12.5 Synergy between the EHS and Generic Prototypes . 214 12.6 More Examples of Exception Handling . 217 13 User-Defined Literal Objects 221 13.1 Literal Numbers . 221 13.2 Literal Objects between Delimiters . 223 14 The Cyan Language Grammar 230 15 Opportunities for Collaboration 235 16 The Cyan Compiler 237 17 Features That May Be Added, Features That May Be Changed 241 3 Foreword This is the manual of Cyan, a prototype-based statically-typed object-oriented language. The language introduces several novelties that makes it easy to implement domain specific languages, reuse the code of methods and nested prototypes (the equivalent of nested classes), blend dynamic and static code, reuse exception treatment, and do several other common tasks. However, the reader should be aware that: 1. the design of Cyan has not finished. There are a lot of things to be designed, the metalevel being one of them (although we cite metaobjects a lot in the text, the compile-time metaobject protocol has not been defined). It is possible that the definition of some language features will be modified, although it is improbable that they will be great changes; 2. many language features need a more detailed description. Probably there are ambiguities in the description of some constructs. That will be corrected in due time; 3. Cyan is a big language, maybe a huge language (unfortunately). But this is fine since Cyan is an academic language. Its main goal is to publish articles. However, there are many small details that were added thinking in the programmer, such as nested if-else statements, while statement, Elvis operator, literal objects, etc; 4. the compiler for a subset of the language is being built. It creates the AST (Abstract Syntax Tree) generates code for a small subset of the language. Cyan code will be able to use Java classes. Since the Cyan compiler produces Java code, this will not be difficult. Java code will be able to use Cyan prototypes (which is a little bit tricker). However, nowhere in this text we talk about interrelations between the two languages; 5. I have thought in how to implement some parts of the language in an efficient way (whenever possible). There was no time to put the ideas in this report. We believe that many flexible constructs, such as considering methods as objects, can be efficiently implemented (they would not be considered objects unless necessary); 6. If you have any suggestions on anything, please email me. The main novelties of Cyan are, in order of importance: (a) grammar methods, Chapter 9; (b) an object-oriented exception handling system, Chapter 12; (c) context objects, Chapter 11; (d) statically-typed blocks, Chapter 10; (e) many ways of mixing dynamic and static typing, Chapter 6; 4 (f) codegs, Section 5.4; (g) context blocks, Section 10.11; (h) literal objects delimited by user-defined symbols, Chapter 13. This feature is being defined; (i) generic objects with variable number of parameters, Chapter 7. (j) a restricted form of multi-methods (search for methods in the textually-declared order), Section 4.12; (k) compilation considers previous version of the source code (source code in XML), Chapter 2; The address of the Cyan home page.
Recommended publications
  • Introduction to Groovy and Grails

    Introduction to Groovy and Grails

    Introduction to Groovy and Grails Mohamed Seifeddine November 25, 2009 1 Contents 1 Foreword 5 2 Introduction to Groovy 7 3 Getting started 9 3.1 Installing Groovy . .9 3.1.1 JDK - A Prerequisite . .9 3.1.2 Installing Groovy . .9 3.2 Updating Groovy . 10 3.3 Editors for Groovy and Grails . 10 3.4 groovysh, groovyConsole & groovy . 10 4 Boolean Evaluation, Elvis Operator & the Safe Navigation Op- erator 13 4.1 Elvis Operator . 15 4.2 Safe Navigation Operator . 15 5 String & GString 19 6 Classes, Dynamic type, Methods, Closures the & Meta-Object Protocol 21 6.1 Dynamic type . 25 6.2 Closure . 29 6.2.1 Create . 29 6.2.2 Call . 30 6.2.3 Getting Information . 33 6.2.4 Method Reference Pointer . 33 6.3 More on Methods . 35 6.3.1 Optional Parantheses . 35 6.3.2 Positional Parameters . 35 6.3.3 Optional Parameters . 36 6.3.4 Mapped Parameters . 37 6.3.5 Dynamic Method Call . 37 6.4 Meta-Object Protocol . 39 6.4.1 Adding Methods & Properties . 39 6.4.2 Add Constructor . 41 6.4.3 Intercepting Method Calls . 41 6.4.4 Getting Information . 42 7 Collections (List, Range, Map) and Iterative Object Methods 47 7.1 List . 47 7.2 Range . 50 7.3 Map . 52 8 Other 55 8.1 Groovy Switch . 55 8.2 Groovy SQL . 56 8.3 File . 58 8.4 Exception Handling . 60 2 8.5 Other . 60 9 Introduction to Grails 61 10 Getting Started 63 10.1 Installing Grails .
  • Chapter 5 Type Declarations

    Chapter 5 Type Declarations

    Ch.5: Type Declarations Plan Chapter 5 Type Declarations (Version of 27 September 2004) 1. Renaming existing types . 5.2 2. Enumeration types . 5.3 3. Constructed types . 5.5 4. Parameterised/polymorphic types . 5.10 5. Exceptions, revisited . 5.12 6. Application: expression evaluation . 5.13 °c P. Flener/IT Dept/Uppsala Univ. FP 5.1 Ch.5: Type Declarations 5.1. Renaming existing types 5.1. Renaming existing types Example: polynomials, revisited Representation of a polynomial by a list of integers: type poly = int list ² Introduction of an abbreviation for the type int list ² The two names denote the same type ² The object [4,2,8] is of type poly and of type int list - type poly = int list ; type poly = int list - type poly2 = int list ; type poly2 = int list - val p:poly = [1,2] ; val p = [1,2] : poly - val p2:poly2 = [1,2] ; val p2 = [1,2] : poly2 - p = p2 ; val it = true : bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.2 Ch.5: Type Declarations 5.2. Enumeration types 5.2. Enumeration types Declaration of a new type having a finite number of values Example (weekend.sml) datatype months = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec datatype days = Mon | Tue | Wed | Thu | Fri | Sat | Sun fun weekend Sat = true | weekend Sun = true | weekend d = false - datatype months = Jan | ... | Dec ; datatype months = Jan | ... | Dec - datatype days = Mon | ... | Sun ; datatype days = Mon | ... | Sun - fun weekend ... ; val weekend = fn : days -> bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.3 Ch.5: Type Declarations 5.2.
  • Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019

    Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019

    Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Jonathan Aldrich, Chair Heather Miller Alex Potanin, Victoria University of Wellington, NZ Submitted in partial fulfillment of the requirements for the degree of Master of Science. Copyright c 2019 Yu Xiang Zhu Keywords: Nominality, Wyvern, Dependent Object Types, Subtype Decidability Abstract This thesis presents Nominal Wyvern, a nominal type system that empha- sizes semantic separation for better usability. Nominal Wyvern is based on the dependent object types (DOT) calculus, which provides greater expressiv- ity than traditional object-oriented languages by incorporating concepts from functional languages. Although DOT is generally perceived to be nominal due to its path-dependent types, it is still a mostly structural system and relies on the free construction of types. This can present usability issues in a subtyping- based system where the semantics of a type are as important as its syntactic structure. Nominal Wyvern overcomes this problem by semantically separat- ing structural type/subtype definitions from ad hoc type refinements and type bound declarations. In doing so, Nominal Wyvern is also able to overcome the subtype undecidability problem of DOT by adopting a semantics-based sep- aration between types responsible for recursive subtype definitions and types that represent concrete data. The result is a more intuitive type system that achieves nominality and decidability while maintaining the expressiveness of F-bounded polymorphism that is used in practice. iv Acknowledgments This research would not have been possible without the support from the following in- dividuals.
  • Cablelabs® Specifications Cablelabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317

    Cablelabs® Specifications Cablelabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317

    CableLabs® Specifications CableLabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317 ISSUED Notice This CableLabs specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. You may download, copy, distribute, and reference the documents herein only for the purpose of developing products or services in accordance with such documents, and educational use. Except as granted by CableLabs in a separate written license agreement, no license is granted to modify the documents herein (except via the Engineering Change process), or to use, copy, modify or distribute the documents for any other purpose. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. To the extent this document contains or refers to documents of third parties, you agree to abide by the terms of any licenses associated with such third-party documents, including open source licenses, if any. Cable Television Laboratories, Inc. 2006-2016 CL-SP-CANN-DHCP-Reg-I13-160317 CableLabs® Specifications DISCLAIMER This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein. Any use or reliance on the information or opinion in this document is at the risk of the user, and CableLabs and its members shall not be liable for any damage or injury incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained in the document.
  • Perception and Effects of Implementing Kotlin in Existing Projects

    Perception and Effects of Implementing Kotlin in Existing Projects

    Bachelor thesis Undergraduate level Perception and effects of implementing Kotlin in existing projects A case study about language adoption Author: Emil Sundin Supervisor: Wei Song Examiner: Azadeh Sarkheyli Discipline: Informatics Course: IK2017 Credit: 15 credits Examination date: 2018-05-25 Dalarna University provides the opportunity for publishing the thesis through DiVA as Open Access. This means that the thesis work will become freely available to read and download through their portal. Dalarna University encourages students as well as researchers to publish their work in the Open Access format. We approve the publishing of this thesis work under the Open Access format: Yes ☒ No ☐ Dalarna University – SE-791 88 Falun – Phone +4623-77 80 00 Abstract The Kotlin programming language has seen an increase of adoption since its launch in 2011. In late 2017 Google announced first-class support for Kotlin on the Android platform which further popularized the language. With this increase in popularity we felt it was interesting to investigate how Kotlin affects the developer experience. We performed a case study to see how Java developers perceive the Kotlin language, and how it meets the requirements of these developers. To gather the developer requirements and their perception of Kotlin we performed two sets of interviews and rewrote parts of their codebase. The first set of interviews identified developer requirements and the second set of interviews showcased the Kotlin language and its potential use in their codebase. The results show that Kotlin can meet most of the developer requirements and that the perception of Kotlin is positive. Kotlin’s ability to be incrementally adopted was a prominent feature which reduced the inherent risks of technology adoption while providing them the ability to further evaluate the language.
  • Project Overview 1 Introduction 2 a Quick Introduction to SOOL

    Project Overview 1 Introduction 2 a Quick Introduction to SOOL

    CMSC 22600 Compilers for Computer Languages Handout 1 Autumn 2016 October 6, 2016 Project Overview 1 Introduction The project for the course is to implement a small object-oriented programming language, called SOOL. The project will consist of four parts: 1. the parser and scanner, which coverts a textual representation of the program into a parse tree representation. 2. the type checker, which checks the parse tree for type correctness and produces a typed ab- stract syntax tree (AST) 3. the normalizer, which converts the typed AST representation into a static single-assignment (SSA) representation. 4. the code generator, which takes the SSA representation and generates LLVM assembly code. Each part of the project builds upon the previous parts, but we will provide reference solutions for previous parts. You will implement the project in the Standard ML programming language and submission of the project milestones will be managed using Phoenixforge. Important note: You are expected to submit code that compiles and that is well documented. Points for project code are assigned 30% for coding style (documentation, choice of variable names, and program structure), and 70% for correctness. Code that does not compile will not receive any points for correctness. 2 A quick introduction to SOOL SOOL is a statically-typed object-oriented language. It supports single inheritance with nominal subtyping and interfaces with structural subtyping. The SOOL version of the classic Hello World program is class main () { meth run () -> void { system.print ("hello world\n"); } } Here we are using the predefined system object to print the message. Every SOOL program has a main class that must have a run function.
  • An Introduction to Lean

    An Introduction to Lean

    An Introduction to Lean Jeremy Avigad Leonardo de Moura Gabriel Ebner and Sebastian Ullrich Version 1fc176a, updated at 2017-01-09 14:16:26 -0500 2 Contents Contents 3 1 Overview 5 1.1 Perspectives on Lean ............................... 5 1.2 Where To Go From Here ............................. 12 2 Defining Objects in Lean 13 2.1 Some Basic Types ................................ 14 2.2 Defining Functions ................................ 17 2.3 Defining New Types ............................... 20 2.4 Records and Structures ............................. 22 2.5 Nonconstructive Definitions ........................... 25 3 Programming in Lean 27 3.1 Evaluating Expressions .............................. 28 3.2 Recursive Definitions ............................... 30 3.3 Inhabited Types, Subtypes, and Option Types . 32 3.4 Monads ...................................... 34 3.5 Input and Output ................................ 35 3.6 An Example: Abstract Syntax ......................... 36 4 Theorem Proving in Lean 38 4.1 Assertions in Dependent Type Theory ..................... 38 4.2 Propositions as Types .............................. 39 4.3 Induction and Calculation ............................ 42 4.4 Axioms ...................................... 45 5 Using Automation in Lean 46 6 Metaprogramming in Lean 47 3 CONTENTS 4 Bibliography 48 1 Overview This introduction offers a tour of Lean and its features, with a number of examples foryou to play around with and explore. If you are reading this in our online tutorial system, you can run examples like the one below by clicking the button that says “try it yourself.” #check "hello world!" The response from Lean appears in the small window underneath the editor text, and also in popup windows that you can read when you hover over the indicators in the left margin. Alternatively, if you have installed Lean and have it running in a stand-alone editor, you can copy and paste examples and try them there.
  • Formats and Protocols for Continuous Data CD-1.1

    Formats and Protocols for Continuous Data CD-1.1

    IDC Software documentation Formats and Protocols for Continuous Data CD-1.1 Document Version: 0.3 Document Edition: English Document Status: Final Document ID: IDC 3.4.3 Document Date: 18 December 2002 IDC Software documentation Formats and Protocols for Continuous Data CD-1.1 Version: 0.3 Notice This document was published December 2002 as Revision 0.3, using layout templates established by the IPT Group of CERN and IDC Corporate Style guidelines. This document is a re-casting of Revision 0.2published in December 2001 as part of the International Data Centre (IDC) Documentation. It was first published in July 2000 and was repub- lished electronically as Revision 0.1 in September 2001 and as Revision 0.2 in December 2001 to include minor changes (see the following Change Page for Revision 0.2). IDC documents that have been changed substantially are indicated by a whole revision number (for example, Revision 1). Trademarks IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. Motorola is a registered trademark of Motorola Inc. SAIC is a trademark of Science Applications International Corporation. Sun is a registered trademark of Sun Microsystems. UNIX is a registered trademark of UNIX System Labs, Inc. This document has been prepared using the Software Documentation Layout Templates that have been prepared by the IPT Group (Information, Process and Technology), IT Division, CERN (The European Laboratory for Particle Physics). For more information, go to http://framemaker.cern.ch/. page ii Final Abstract Version: 0.3 Abstract This document describes the formats and protocols of Continuous Data (CD-1.1), a standard to be used for transmitting continuous, time series data from stations of the International Monitoring System (IMS) to the International Data Centre (IDC) and for transmitting these data from the IDC to National Data Centers (NDCs).
  • Parts 43 and 45 Technical Specifications

    Parts 43 and 45 Technical Specifications

    CFTC Technical Specification Parts 43 and 45 swap data reporting and public dissemination requirements September 17, 2020 Version 2.0 This Technical Specification document (“Tech Spec”) provides technical specifications for reporting swap data to Swap Data Repositories (SDRs) under parts 43 and 45. i TABLE OF CONTENTS INDEX OF DATA ELEMENTS ........................................................................................................................................................................................... III 1 INTRODUCTION ................................................................................................................................................................................................. VI 1.1 BACKGROUND .................................................................................................................................................................................................................. VI 1.2 STRUCTURE AND DESCRIPTION OF COLUMN HEADINGS ............................................................................................................................................................ VI 1.3 EXPLANATION OF DATA ELEMENT OR CATEGORY .................................................................................................................................................................... IX 1.4 UNIQUE PRODUCT IDENTIFIER (UPI) ....................................................................................................................................................................................
  • Groovy and Java: a Comparison Groovy’S Resemblance to Java Is Often Quite Striking

    Groovy and Java: a Comparison Groovy’S Resemblance to Java Is Often Quite Striking

    APPENDIX ■ ■ ■ The Groovy Language Groovy is an all-purpose programming language for the JVM. It was born in 2003 when James Strachan and Bob McWhirter founded the Groovy project with the goal of creating a glue lan- guage to easily combine existing frameworks and components. Groovy is a language that aims to bring the expressiveness of languages such as Ruby, Lisp, and Python to the Java platform while still remaining Java friendly. It attracted much excitement with these ambitious goals, because the majority of other scripting languages on the Java platform either used an entirely alien syntax and APIs or were simply Java without the need to specify types. Despite its youth, Groovy is a stable, feature-rich language that forms the perfect base for Grails. This is a fantastic achievement, given the limited resources available to an open source project such as Groovy. Groovy was an obvious choice as a platform for the Grails framework, because it provides the necessary underlying infrastructure to create the diverse range of miniature domain-specific languages utilized throughout Grails. ■Note Martin Fowler has written an excellent article about domain-specific languages: http://www.mar- tinfowler.com/bliki/DomainSpecificLanguage.html. What does this mean? Well, the syntax you see used throughout the book has often been magically enhanced and shortened by using a combination of Groovy’s already concise syntax and its support for metaprogramming. Groovy performs a lot of magic under the covers, abstracted away from the developer. This removes the burden from the programmer who would otherwise be required to write reams of unnecessary, repetitive code.
  • Datatypes in Isabelle/HOL

    Datatypes in Isabelle/HOL

    Defining (Co)datatypes in Isabelle/HOL Jasmin Christian Blanchette, Lorenz Panny, Andrei Popescu, and Dmitriy Traytel Institut f¨urInformatik, Technische Universit¨atM¨unchen 5 December 2013 Abstract This tutorial describes how to use the new package for defining data- types and codatatypes in Isabelle/HOL. The package provides five main commands: datatype new, codatatype, primrec new, prim- corecursive, and primcorec. The commands suffixed by new are intended to subsume, and eventually replace, the corresponding com- mands from the old datatype package. Contents 1 Introduction3 2 Defining Datatypes5 2.1 Introductory Examples.....................5 2.1.1 Nonrecursive Types...................5 2.1.2 Simple Recursion.....................6 2.1.3 Mutual Recursion....................6 2.1.4 Nested Recursion.....................6 2.1.5 Custom Names and Syntaxes..............7 2.2 Command Syntax........................8 2.2.1 datatype new .....................8 2.2.2 datatype new compat ................ 11 2.3 Generated Constants....................... 12 2.4 Generated Theorems....................... 12 2.4.1 Free Constructor Theorems............... 13 1 CONTENTS 2 2.4.2 Functorial Theorems................... 15 2.4.3 Inductive Theorems................... 15 2.5 Compatibility Issues....................... 16 3 Defining Recursive Functions 17 3.1 Introductory Examples..................... 17 3.1.1 Nonrecursive Types................... 17 3.1.2 Simple Recursion..................... 17 3.1.3 Mutual Recursion.................... 18 3.1.4 Nested Recursion..................... 19 3.1.5 Nested-as-Mutual Recursion............... 20 3.2 Command Syntax........................ 20 3.2.1 primrec new ...................... 20 3.3 Recursive Default Values for Selectors............. 21 3.4 Compatibility Issues....................... 22 4 Defining Codatatypes 22 4.1 Introductory Examples..................... 22 4.1.1 Simple Corecursion................... 22 4.1.2 Mutual Corecursion..................
  • Over the Counter Options User Manual

    Over the Counter Options User Manual

    Over the Counter Options Oracle FLEXCUBE Universal Banking Release 12.0 [June] [2012] Oracle Part Number E51527-01 Over the Counter Options Table of Contents 1. ABOUT THIS MANUAL ................................................................................................................................ 1-1 1.1 INTRODUCTION ........................................................................................................................................... 1-1 1.2 AUDIENCE .................................................................................................................................................. 1-1 1.3 ACRONYMS AND ABBREVIATIONS .............................................................................................................. 1-1 1.4 ORGANIZATION .......................................................................................................................................... 1-1 1.5 RELATED DOCUMENTS ............................................................................................................................... 1-2 1.6 GLOSSARY OF ICONS .................................................................................................................................. 1-2 2. OVER THE COUNTER OPTIONS – AN OVERVIEW ............................................................................. 2-1 2.1 INTRODUCTION ........................................................................................................................................... 2-1 2.2 OTC INSTRUMENTS AND