title: Designing the type system of a simple statically typed language (in Haskell)
body: <p>I've been toying with the idea of writing an interpreter for an imperative, statically typed language to get used to functional programming and Haskell, however I've never really had a clear grammar in mind, which often lead to unsatisfying code and the urge to rewrite everything so I came here for help. How should I go about designing a relatively simple but extensible type system?</p>
  
  <p>I want to support basic primitives like numeric types, booleans, chars, etc. (don't want to dabble with arrays or record structures until I've got the basics in place) and their associated basic operations. My biggest issue is that I don't exactly know how the relation between types and operators should be implemented.</p>
  
  <p>I don't know much about Haskell yet, but the simple solution of defining a bunch of repetitive sum types like</p>
  
  <pre><code>data ArithmeticOperator =
      Plus
      | Min
      | Mul 
      | Div
  
  data LogicalOperator =
      And
      | Or
      | Not
  </code></pre>
  
  <p>doesn't seem to eloquent to me, since this type division would further propagate into the structures that build upon these types like expressions, and having to pattern match each operator when evaluating expressions seems really tedious and not easily extendable. </p>
  
  <p>So then I thought about defining a flexible type for operators, like</p>
  
  <pre><code>data Operator a b =
      UnaryOperator (a -&gt; b)
      | BinaryOperator (a -&gt; a -&gt; b)
  </code></pre>
  
  <p>where a stands for the parameters type and b is the return type. Problem with this is that I don't really know how to enforce the types to be only the ones that I intend to support. It looks more concise but I'm not sure if this is "right" either.</p>
  
  <p>Finally, are there any resources that introduce this topic in a beginner friendly way? I wouldn't want to get too deep in the subject, but I'd love to read about.. well, common principles/considerations when it comes to designing a type system. </p>