#typeclass

之前看Haskell相关的文章时，总是各种吹捧其类型系统如何强大，而且是一谈Haskell，立刻聊到函数式编程，立刻聊到Monad，立刻聊到范畴论，立刻聊到数学。

趁今年春节没出远门，就在Kindle上买了一本《Haskell趣学指南》，学一点电（工）视（作）上不让播（用）的冷门知识。而且这回学习的目标也非常明确——解答“Haskell的类型系统与语言的差别”与“Monad解决什么问题”两个疑惑。陆陆续续看完了教程，也查看了一些相关资料，心中已经有了基本的答案，因此记录下来。为了方便以后自己理解和回忆，所有Haskell的概念与代码都会尽量提供等价或相近的Java概念与代码。

类型系统

关于类型系统的差异，知乎上有个非常好的问题《Haskell的类型类是否遵循里式替换原则？》。文中提到一个例子：

> :type fromIntegral fromIntegral :: (Integral a, Num b) => a -> b > :type sqrt sqrt :: Floating a => a -> a > :type sqrt . fromIntegral sqrt . fromIntegral :: (Floating c, Integral a) => a -> c

上述三行代码分别返回三个函数的出入参类型：

fromIntegral函数：入参a是Integral，出参b是Num。

sqrt函数：入参与出参都是Floating。

组合函数sqrt . fromIntegral：等价于将fromIntegral的输出作为sqrt的输入，入参a是Integral，出参c是Floating。

为方便理解，Haskell的Integral类型可以看成Integer，Num可以看成Number，Floating可以看成Float。在Haskell中，Num可以理解为Integral与Floating公共基类，Java中Number同样也是Integer与Float的基类。因此，上述三个函数等价的Java方法定义如下：

Number fromIntegral(Integer a); Float sqrt(Float a);

在Java中调用sqrt(fromIntegral(...))会直接报编译错误，因为Number是Float的基类，无法作为sqrt的入参；但Haskell代码却可以正常执行！

类型类

究其原因，是因为Num并不是类型（class），而是类型类（type class）。类型类可以看成是类型的约束，Java中类似的概念是“接口+泛型”。因此fromIntegral不能读作“返回Num类型的函数”，而应该读作“返回任何一个符合Num约束的类型的函数”。Java较相近的写法如下：

T fromIntegral(Integer a);

至于函数具体返回哪一个符合Num约束的类型，在定义fromIntegral的时候并不知道，Haskell编译器会通过类型推导功能，在每一处函数调用的地方，动态地算出真正的类型。

上述例子中，sqrt的入参Floating实际上也是类型类，因此组合sqrt与fromIntegral时，类型系统会要求fromIntegral的返回值类型既要满足Num的约束也要满足Floating的约束，由于Floating就是Num的子类型类，因此fromIntegral函数的返回值约束动态地变成了满足Floating约束。

面向接口编程

其中里氏替换原则（Liskov Substitution Principle）是指继承必须确保超类所拥有的性质在子类中仍然成立，即子类可以扩展父类的功能，但不能改变父类原有的功能。

In Scala you can impose a constraint on a type parameter (T) saying that, T has to have a binding with another type. I hope this sounds too abstract. Lets write an example,

Consider there are 2 types

case class Address(doorNo: Int, streetName: String, area: String, city: String, pincode: Int, country: String) case class Name(sal: String, fn: String, ln: String)

we are to build a formatted String out of these two types meaning, the common agenda is to build a formatted string . Lets define a type for that too so that we can pass any type.

trait LabelMaker[T] { def printLabel(t: T): String }

Now lets implement the trait to implement formatted string for Address and Name case classes.

object LabelMaker { implicit object IndianAddressLabelMaker extends LabelMaker[Address] { def printLabel(t: Address): String = s"""%d, %s, |%s, |%s - %d, |%s """.stripMargin.format(t.doorNo, t.streetName, t.area, t.city, t.pincode, t.country) } implicit object NameLabelWriter extends LabelMaker[Name] { override def printLabel(t: Name): String = """%s.%s %s""".format(t.sal, t.fn, t.ln) } }

(Note : type enthusiast would have figured out that Iam speaking about type classes !!!)

Now Lets use LabelMaker to format our types a naive implementation would like below

def printLabel[T](t:T)(lm:LabelMaker[T]) = lm.printLabel(t) val x: (LabelMaker[Address]) => String = printLabel(address)

it works, but x results in another function where we have to pass an implementation of LabelMaker.

Lets improve this such that we can infer the LabelMaker from surrounding context using implicits.

val address = Address(4, "pkwms", "sw", "c", 600015, "I") def printLabel[T](t:T)(implicit lm:LabelMaker[T]) = lm.printLabel(t) val x: String = printLabel(address)

now that we are not passing any LabelMaker implementation.

Here comes the deal breaker, now lets say that we have another type called DateOfBirth and we want to create a formattedString out of it.

case class DateOfBirth(day: String, dateOfMonth: Int, month: String, year: Int)

so If we use it saying

val dob = DateOfBirth("Fri", 15, "Jun", 1984) printLabel(dob)

this won't compile as we don yet have the implementation for DateOfBirth. (Note: none of the IDE's today could catch this error inline as you code, it get caught when you compile)

Lets change the printLabel function,

def printLabel[T: LabelMaker](t: T) = implicitly[LabelMaker[T]].printLabel(t)

As you can see we removed the implicit parameter and used something called implicitly , this is where context bounds could be used , If you see in the PrintLabel object we have implicit object which Implement LabelMaker such that we are saying that Address and Name types has a bound to an Implementation of LabelMaker. This is being represented in the function such that it expects that the generic type parameter T has a bound to LabelMaker as defined in [T:LabelMaker]. The compiler will throw an error if it could not find the binding to LabelMaker for T.

In the right side of the function we use implicitly keyword to access the printLabel funciton from the implicit parameter.

so when we use this nothing really changes ....

printLabel(address)

Consider having all the traits , case classes and companion traits in the same package to avoid confusion.

  Scrhift Muss Passen by L. Nettlehorst

Schrift Muss Passen was published in 1959 for Essen, a business and advertising publishing company. The name translates roughly to Writing Must Fit Font Choice; it’s so much nicer in German, isn’t it? (How often can you even say that, anyway?) The book appears within a larger work calledWritten Expression in Advertising; Manual for the Artwork of Advertising Materials, a book that focuses on the proper use of typography in advertising materials. Like every other scholarly text we’ve toured during Type Class Tuesdays, it also includes a thorough classification system.

Schrift Muss Passen offers the first system in which the Lineal category has been sub-classified, though part of that credit is due to Maximilien Vox, who was working on a revised version of his 1954 system (in conjunction with ATypI—tune in next week) that included four subcategories for the Lineals. Schrift Muss Passen has two subclasses: Grotesk and Humanist. It’s simple and a good start, but it would be difficult to force a geometric sans serif face, like Futura or Gotham into either of those two categories, and since there is no catch-all (read: Display) section in this system, there would be no place for these faces to go (sad face).

Nettlehorst’s classification of Blackletter is typical, though missing a Rotunda category. Considering this classification was written in German (so excuse us if our translations are a wee-bit off), it’s a smidge bizarre that the Blackletter is not appropriately fawned over.

The breakdown of Serifs, which Nettlehorst calls Roman is interesting. This is certainly not the first system to classify the serif by period, but it is the first to do it so succinctly. Ultimately, Vox’s choices become more standard, with terms like Venetian and Transitional, but at this point, prior to the publication of the Vox/ATypI collaboration, those terms had not yet caught on. 

At this time, scholars hadn’t yet figured out what to do with the emerging Slab Serif category. Nettlehorst places it under Lineals, a term Vox used to describe Sans-Serifs, which makes sense given that Nettlehorst calls does not classify his serifs by their terminals, but by their historic period (Roman). Slab Serifs are certainly much more Lineal than they are Roman, after all.

This kid wasn’t messing around when it came to typeface classification.

Daniel Berkeley Updike was an American printer and typographic historian. In 1893, he founded the Merrymount Press in Providence, Rhode Island with the express purpose of doing “common work well.” Could you imagine? There used to be a time when hand-set printing was common. We were all born in the wrong era. Ultimately, his excellence in printing inspired other printers. He taught the first college course in the United States on this history of typography, and the practice of printing at Harvard University. 

In 1922, he published his sweeping scholarly achievement: Printing Types: Their History, Forms, and Use in 1922 which covers typography from before the golden age of printing, well through to the opening of the twentieth century.

In Printing Types, Updike discusses 15th century printing types in Europe with astounding depth, far more depth, in fact than could be captured within our pie chart system. Shown above is the paired down version of his typeface classification system. To see the detailed version, one would have to imagine six of these charts—one each for Germany, Italy, France, The Netherlands, Spain and England).

There would then be some differentiations in those charts. Only the Italian chart would have the Italic, which it would use over the Vernacular classification. Germany’s Gothic types would be called Textura, Fraktura and Schwabacher (say that 5 times fast).

England would remove the Classical Roman classification and Spain would lose the vernacular category. It would also have a Woodcut Capitals classification, which brings up a whole other mess–should there also be printing based classification? (Probably) And how would that work? (Ugh, we’ll save that for another post.)

In addition to detailing the most in-depth classification system, Updike discusses nearly all of the known printers of each country, which typefaces they used, and their contributions to the art of letterpress printing. Can you say workaholic? We’re glad though. He’s pretty much the 1920s James Bond of typefaces­–attempting to crack all the typographic mysteries with his never-ending knowledge. He kind of reminds us of Paul Shaw, one of our favorite professors who happens to be an extremely knowledgeable historian and talented calligrapher.