3 ms·

Type systems mean different things in different languages. This is trying to apply one language's type philosophy to another language. In Haskell, a type repre

by lmkg 14y ago

Type systems mean different things in different languages. This is trying to apply one language's type philosophy to another language. In Haskell, a type represents the results of performing a computation. The "results" include the "output" but are not limited to it: they also include things like state changes, possible exceptions, and I/O. That's why Haskell is so big on Monads, because that's the best way to embed these results into a return value. In a systems language like C or Rust, a type represents the size and meaning of an area of memory: is it an int, a float, a pointer to a float that stays constant, or a pointer to a float that someone else can change? In languages like C# & Java, a type represents something like the allowable operations on a value, usually represented as the list of methods on a class. What this article is basically doing is taking a type system of the third category (C#, allowable operations), and embedding into it a type system of the first category (result of computation). While there are advantages to Haskell's approach, I'm not convinced the metaphor shear is worth the effort here. Your types end up expressing things that no other part of the language cares about or can make use of.

noblethrasher 14y ago
I'm writing a parser and I noticed that my code turned out quite a bit simpler when I decided to rename a class to "Tokenized" rather than "Tokenizer". In the case of C#, Java, et al, I think limiting the type system to “expressing allowable operations” is due to habit and custom rather than something intrinsic to language. In my mind, the purpose of a computation is to create new/more structure so that, on the surface, your program ends up being a series of simple queries rather than a bunch of messy computations using complex algorithms. Classical OOP in which the constructor does the computation and the methods do the querying on the new encapsulated structure seems to be a good fit for that. This is subtly different than treating methods as allowable operations because we’re not concerned with transforming the structure, just asking easy questions about it. So in this way, OOP à la C# is very similar to FP à la Haskell.

by lmkg 14y ago

noblethrasher 14y ago

I'm writing a parser and I noticed that my code turned out quite a bit simpler when I decided to rename a class to "Tokenized" rather than "Tokenizer". In the case of C#, Java, et al, I think limiting the type system to “expressing allowable operations” is due to habit and custom rather than something intrinsic to language. In my mind, the purpose of a computation is to create new/more structure so that, on the surface, your program ends up being a series of simple queries rather than a bunch of messy computations using complex algorithms. Classical OOP in which the constructor does the computation and the methods do the querying on the new encapsulated structure seems to be a good fit for that. This is subtly different than treating methods as allowable operations because we’re not concerned with transforming the structure, just asking easy questions about it. So in this way, OOP à la C# is very similar to FP à la Haskell.