Drop higher kinded polymorphism (hkp) for now
Do not want the community to get distracted trying to be like Haskell
when the goal is to be better than JavaScript.
Articles about making an app that looks great are positive for Elm!
Articles about how simple it is to architect and maintain an Elm app
are great! Articles about how to make your code super generic using
category theory are going to alienate people, especially if you are not
*doing* anything with these abilities.
commita1a625513da3700d8e6240bd953bc4ba9bb720d4
authorEvan Czaplicki <info@elm-lang.org>
dateTue 22 Jul 2014, 13:05 (12 years ago)
parenta70ee89
changelog.md−1
@@ -8,7 +8,6 @@
88 * Add Keyboard.alt and Keyboard.meta
99 * Add Debug.crash
1010 * Add --bundle-runtime flag which creates stand-alone Elm programs
11− * Higher kinded polymorphism (a.k.a. higher-order types)
1211 * Many bug fixes for imports and exports
1312 * Better architecture for compiler. Uses types to make compilation pipeline
1413 safer, setting things up for giving programmatic access to the AST to
compiler/Parse/Type.hs+1−1
@@ -54,7 +54,7 @@ term = list <|> tuple <|> record <|> tvar <|> constructor0
5454
5555app :: IParser T.RawType
5656app =
57− do f <- constructor0 <|> tvar <|> try tupleCtor <?> "type constructor"
57+ do f <- constructor0 <|> try tupleCtor <?> "type constructor"
5858 args <- spacePrefix term
5959 return $ case args of
6060 [] -> f