3 ms·

I would have used the word "features" or "extensions" instead of "styles" but I agree with rattray's point, if I understand it correctly. It seems like every Ha

I would have used the word "features" or "extensions" instead of "styles" but I agree with rattray's point, if I understand it correctly. It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. This makes me feel that, totally apart from the syntax, Haskell/GHC is still more of a laboratory for doing programming language research. Which is great for what it is; I would say Haskell's original motto "avoid popularity at all costs" still holds. I also had hope for languages like PureScript that make an opinionated choice about a subset of those features for the sake of a consistent development framework.

unhammer 6y ago
> each of which requires some deep knowledge of type theory to understand how it affects the language This is simply false. Quite a few of them are not much more than syntax sugars, e.g. with LambdaCase I can write eitherToMaybe = \case Left _ -> Nothing Right x -> Just x instead of eitherToMaybe var = case var of Left _ -> Nothing Right x -> Just x With OverloadedStrings I can write "foo" instead of (T.pack "foo") or whatever and it picks the right "pack" function based on the inferred type. OverloadedLists does the same for listy things, e.g. now [1] can be a literal vector and you don't have to say V.fromList [1]. TupleSections lets you write (1,) when you want a function that tuples something with 1 (so (1,) applied to 2 becomes (1,2)). NamedFieldPuns lets you write foo x = let myField = x + 1 in MyType{myField} instead of foo x = let thing = x + 1 in MyType{myField = thing} ----- And then there are a bunch of "Deriving…" extensions that don't require any knowledge either, you just enable the pragma, and it lets you say e.g. data X … deriving (FromJSON) instead of having to explicitly implement the FromJSON instance by hand. I have used Deriving a bunch and have no idea how they work :-) Looking through my main project, the only other extension I use on a regular basis is ScopedTypeVariables. That one's a bit more difficult to explain since you have to have some idea what the words "scope" and "type variable" mean, but basically lets you refer to a type variable from the outer function signature in the type signature of a where-clause. Normally, with foo :: Maybe a -> Int … where helper :: Maybe a -> Int the a's are seen as different types. With ScopedTypeVariables, you can say foo :: forall a. Maybe a -> Int … where helper :: Maybe a -> Int and the a's are the same type. So that lets you have explicit type sigs on helper functions that are restricted to the type of the outer function. (Though I am not an expert on this so maybe I've got it all wrong. But that doesn't stop me from using it to make stuff with.)

unhammer 6y ago

> each of which requires some deep knowledge of type theory to understand how it affects the language This is simply false. Quite a few of them are not much more than syntax sugars, e.g. with LambdaCase I can write eitherToMaybe = \case Left _ -> Nothing Right x -> Just x instead of eitherToMaybe var = case var of Left _ -> Nothing Right x -> Just x With OverloadedStrings I can write "foo" instead of (T.pack "foo") or whatever and it picks the right "pack" function based on the inferred type. OverloadedLists does the same for listy things, e.g. now [1] can be a literal vector and you don't have to say V.fromList [1]. TupleSections lets you write (1,) when you want a function that tuples something with 1 (so (1,) applied to 2 becomes (1,2)). NamedFieldPuns lets you write foo x = let myField = x + 1 in MyType{myField} instead of foo x = let thing = x + 1 in MyType{myField = thing} ----- And then there are a bunch of "Deriving…" extensions that don't require any knowledge either, you just enable the pragma, and it lets you say e.g. data X … deriving (FromJSON) instead of having to explicitly implement the FromJSON instance by hand. I have used Deriving a bunch and have no idea how they work :-) Looking through my main project, the only other extension I use on a regular basis is ScopedTypeVariables. That one's a bit more difficult to explain since you have to have some idea what the words "scope" and "type variable" mean, but basically lets you refer to a type variable from the outer function signature in the type signature of a where-clause. Normally, with foo :: Maybe a -> Int … where helper :: Maybe a -> Int the a's are seen as different types. With ScopedTypeVariables, you can say foo :: forall a. Maybe a -> Int … where helper :: Maybe a -> Int and the a's are the same type. So that lets you have explicit type sigs on helper functions that are restricted to the type of the outer function. (Though I am not an expert on this so maybe I've got it all wrong. But that doesn't stop me from using it to make stuff with.)