Haskell Type class, a state of the art Haskell computer (Marlow (Ed), 2010, offers numerous extension to the standard Haskell type system (schrigvers, 2009., Yorgey et all, 2012, Kislyov et al; 201; Peyton Jones et al; 2007). Each of these extension is usually specified only semiformal and only in isolation very litter work has been done examining type system properties when multiple type system extension are combined which is the scenic actually being faced by Haskall type class developers. To address this, the Haskell type class team published outsidelnpxq, a musthy- vigorous formulation of Haskell type class, type inference system (Vytiniotis, 2011), which encompassed very types, system extension developed for Haskell type class to data. We formalize outsidenxq in a mechanical proofs assistant, in order to provide a body of formal works up9on which future extensions can be developed. By using a mechanical proofs assistant we not only ensure correction of our proofs and complete rigour in our definitions, but also make possible the incremental development of the formal work alongside the more practically-minded type checker implementation in Haskell type class. This additional accessibility will hope fully prevent further extension from being developed without regared to the effect such an extension many have an other parts of the types system. Our formulization is developed in (Norell, 2008).As a dependently types programming language which unforced totally, double as a proof assistant (Hourard, 1980), it is still under heavy development, and is quite experimental. By formalizing outsidelnpxy, we demonstrate its readiness for type system work, and also provide as example to encourage further type system research.

TABLE OF CONTENTS

Title page i

Certificate ii

Approval iii

Dedication iv

Acknowledgement v

Abstract vi

Table of content vii

CHAPTER ONE

1.0 Introduction 1

1.1 Statement of problem 4

1.2 Significance 5

1.3 Aims and objectives 5

1.4 Scope of study 6

1.5 Assumption 6

1.6 Definition terms 7

CHAPTER TWO

2.0 Literature review 8

CHAPTER THREE

3.0 Method for fact finding and detailed discussions of the system 12

3.1 Methodologies for fact finding 12

3.2 Discussion 12

CHAPTER FOUR

4.0 Futures, implications and challenges of the system 18

4.1 Futures 18

4.2 Implications 19

4.3 Challenges 21

CHAPTER FIVE

5.0 Recommendations, summary, conclusion and references 23

5.1 Recommendation 23

5.2 Summary 23

5.3 Conclusion 24

References 26

CHAPTER ONE

6.0 INTRODUCTION

Haskell is a purely functional programming language, with a type system that supports algebraic data types, type inference, parametric (Highter-Kinded) polymorphism, and type class constraints (Marlow (Ed), 2012). In recent years, the developers of GHC, a prominent Haskell compiler, have implemented a variety of extensions to this type system, with the aim of providing greater expressiveness, ease of use, or static verification capabilities. Some are straight forward, such as generalizing type classes to type relations via milti-parameter types classes. Some require more significant extensions to the type system, such as type families (Kiselyov et al; 2012) and the earlier functional dependencies extension; some make types inference significantly more difficult and major extension, such as GADTS (Schrijvers et al; 2009), impredicative polymorphism and arbibrary-rank types (Peyton Jones et al; 2007). While GHC accommodates all of these extension simultaneously, the papers that introduce each one discuses type inference and types checking only in isolation, and sometimes quite informally. This is makes the properties of GHC’s types reconstruction algrittm difficult to determine when multiple extension are combined. As a first step towards solving this problem, the GHC team (specifically vytinidis, Peyton Jones, Schigvers and Surmann) published outdid inpxq, a modular type inference system that accommodates all of the extension (and possibly more), along with soundness and principality proofs (Vytinitis et al; 2011) our work aims to more ruinously formalize outsidelnpxq in the dependently-typed programming language cum proof assistant Agda 2 (Norell, 2008). The outsidelnpxq system itself is similar in presentation of ML’S type inference, first presented in (orderky et al; 1997) and more rigorously formalized in (Potter and Remy, 2005). It is the culmination of years of work and is the latest in a series of types inference system for GADTs in Haskell based on “Wobbly types” (Schrijvers et al; 2009) right up to the very similar LHMPXQ system presented in (Vytiniotis et al; 2012). Types inference in a proof assistant, and what litte5r work that has been done is primarily focused on types inference for Ml. Nipkow and Narachewski have formalized Milners’s original W algorithm for the HM calculus in lsabelle/HOL and proven soundness (Naraschewski and Nipkow, 1999), and Dubois et al; simultaneously performed a similar verification in coq (Dubois, Menissier-Morais, 1999 for the purposes of developing a certified ML compiler (Dubois, 2000), surprisingly, no types inference algorithm have been formalized in Agda before.

Even more surprisingly, no algorithm which includes support for GADTs or other advanced types system features had ever been formalized in a proof assistant, to our knowledge. The techniques we use for term representation are drawn heavily from Bird’s observation of monadic structure in syntax trees (Bird and Paterson, 1999), a concept first explored in (Bellegard and Hook, 1994). We also draw several representational ticks from work in generic programming using dependent types (Morris et al; 2004) and Mc Bride’s works on structurally recursive unification (McBride, 2003), which is used directly in our simple in sanitation.

Why mechanize outsidelnpxq?

Any handwritten formalization or proof will likely lack the amount of rigour necessary to be accepted by a proof assistant, much like a handwrite algorithm is unlikely to be accepted by a programming language compiler. Formalizing outsideinpxq in a proof assistant is therefore more difficult than it proof assistant requires use to redesign those parts of the system that are not amenable to automated checking, and to make rigorous all those parts of the originals intuition. By formalizing outsideinpxq in a proof assistant,, we achieve two main goals.

Firstly, we make explicit that which was implicitly and to prove that which was assumed in the original outsideinpxq paper, ensuring that our formal work stands on solid ground’s and secondly, we encourage those developing extensions fro the types system formalization, along with the necessary practical implementation of the new extension in GHC’s type checker. By making run formalization available as code, we hope to mitigate the social problem of formal work on a type system being publishing in a long paper and subsequently ignored.