
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">


<div dir="ltr" class=""><span class="">Hopefully not too late to the party, but here are my votes. Like Richard’s, anything other than “yes” or “no” is the reason why it’s a “no”.</span></div>


<div dir="ltr" class=""><b class=""><br class="">


</b></div>


<div dir="ltr" class=""><b class="">Module System<br class="">


=============</b><br class="">


<br class="">


ImportQualifiedPost: yes<br class="">


PackageImports: yes<br class="">


NoImplicitPrelude: a very breaking change<br class="">


<br class="">


<b class="">Notation<br class="">


========</b><br class="">


<br class="">


BlockArguments: yes<br class="">


MultiWayIf: yes<br class="">


LambdaCase: yes<br class="">


BinaryLiterals: yes<br class="">


HexFloatLiterals: yes<br class="">


NumericUnderscores: yes<br class="">


NumDecimals: yes<br class="">


OverloadedStrings: more problems along the lines of `show 1` that seem to trip up a lot of newcomers.<br class="">


OverloadedLists: same as OverloadedStrings<br class="">


OverloadedLabels: not a no as much as a "no strong opinion" - personally never preferred it over alternatives.<br class="">


EmptyCase: yes<br class="">


PostfixOperators: yes<br class="">


LexicalNegation: yes<br class="">


UnicodeSyntax: yes<br class="">


NegativeLiterals: yes / N/A<br class="">


TupleSections: yes<br class="">


ImplicitParams: not obvious syntax, turning it on in cabal files/pragmas gives unfamiliar readers something to search for<br class="">


ParallelListComp: yes<br class="">


RecursiveDo: no strong opinion, I’ve never needed/used it in practice<br class="">


TransformListComp: adds more complexity to list comp notation, which is already complexity on do-notation<br class="">


Arrows: no strong opinion, but I’d lean towards no for the same reason as ImplicitParams<br class="">


ApplicativeDo: probably quite a breaking change in practice<br class="">


QualifiedDo: no<br class="">


MonadComprehensions: no<br class="">


NondecreasingIndentation: I had no idea about this until I saw the user guide example - this is probably unintuitive</div>


<div dir="ltr" class="">RebindableSyntax: definitely a breaking change, not least because it implies NoImplicitPrelude<br class="">


ExplicitNamespaces: yes<br class="">


<div class=""><br class="">


</div>


<div class=""><b class="">Data Types<br class="">


==========<br class="">


</b><br class="">


DatatypeContexts: no<br class="">


ExistentialQuantification: yes<br class="">


EmptyDataDecls: yes<br class="">


RoleAnnotations: yes<br class="">


StrictData: no, definitely a breaking change<br class="">


GADTSyntax: yes<br class="">


GADTs: the implied MonoLocalBinds probably means this would be a breaking change<br class="">


</div>


<div class=""><br class="">


</div>


<div class=""><b class="">Patterns and Guards<br class="">


===================</b><br class="">


<br class="">


</div>


<div class="">BangPatterns: yes<br class="">


ViewPatterns: yes<br class="">


PatternSynonyms: no<br class="">


NoPatternGuards: no<br class="">


NPlusKPatterns: no<br class="">


<br class="">


<b class="">Records<br class="">


=======</b><br class="">


<br class="">


NamedFieldPuns: yes<br class="">


RecordWildCards: yes, but a weak yes<br class="">


DisambiguateRecordFields: yes<br class="">


DuplicateRecordFields: yes<br class="">


NoTraditionalRecordSyntax: no<br class="">


<br class="">


</div>


<div class=""><b class="">Deriving<br class="">


=======</b><br class="">


<br class="">


DeriveGeneric: yes<br class="">


DeriveLift: yes<br class="">


DeriveDataTypeable: yes<br class="">


EmptyDataDeriving: yes<br class="">


StandaloneDeriving: yes<br class="">


DeriveFunctor: yes<br class="">


DeriveFoldable: yes<br class="">


DeriveTraversable: yes<br class="">


DerivingStrategies: yes<br class="">


DerivingVia: yes<br class="">


GeneralisedNewtypeDeriving: yes<br class="">


DeriveAnyClass: no, I can imagine this would be rather dangerous<br class="">


</div>


<div class=""><br class="">


</div>


<div class=""><b class="">Class System<br class="">


============</b><br class="">


<br class="">


MultiParamTypeClasses: yes<br class="">


NullaryTypeClasses: yes (albeit implied)<br class="">


ConstraintKinds: yes<br class="">


TypeSynonymInstances: yes<br class="">


FlexibleInstances: yes<br class="">


FlexibleContexts: yes<br class="">


ConstrainedClassMethods: yes<br class="">


DefaultSignatures: yes<br class="">


InstanceSigs: yes<br class="">


ExtendedDefaultRules: leads to some unexpected error messages<br class="">


FunctionalDependencies: yes<br class="">


QuantifiedConstraints: probably too new<br class="">


UndecidableInstances: noooo<br class="">


IncoherentInstances: noooo</div>


<div class="">UndecidableSuperClasses: noooo<br class="">


OverlappingInstances: noooo<br class="">


<b class=""><br class="">


</b></div>


<div class="">Types<br class="">


<b class="">=====</b><br class="">


<br class="">


RankNTypes: yes<br class="">


StandaloneKindSignatures: yes<br class="">


KindSignatures: yes<br class="">


LiberalTypeSynonyms: yes<br class="">


ScopedTypeVariables: yes<br class="">


ExplicitForAll: yes<br class="">


AllowAmbiguousTypes: the class-site error is more useful than the use-site<br class="">


ImpredicativeTypes: not yet<br class="">


MonoLocalBinds: definitely a breaking change<br class="">


NoMonomorphismRestriction: I’d lean weakly towards “yes”, but happy to be overruled.<br class="">


PartialTypeSignatures: no<br class="">


NamedWildCards: yes<br class="">


LinearTypes: no<br class="">


TypeApplications: yes<br class="">


PolyKinds: yes<br class="">


TypeOperators: yes<br class="">


StarIsType: no, or even No<br class="">


TypeFamilies: yes<br class="">


TypeFamilyDependencies: yes<br class="">


DataKinds: yes<br class="">


<br class="">


</div>


<div class=""><b class="">FFI<br class="">


===</b><br class="">


<br class="">


ForeignFunctionInterface: no<br class="">


CApiFFI: no<br class="">


GHCForeignImportPrim: no<br class="">


InterruptibleFFI: no<br class="">


UnliftedFFITypes: no<br class="">


StaticPointers: no<br class="">


<br class="">


<b class="">Low Level<br class="">


=========</b><br class="">


<br class="">


UnboxedSums: yes<br class="">


UnboxedTuples: yes<br class="">


MagicHash: yes<br class="">


UnliftedNewtypes: yes<br class="">


<br class="">


<b class="">Macros<br class="">


======</b><br class="">


<br class="">


CPP: no<br class="">


TemplateHaskell: yes<br class="">


TemplateHaskellQuotes: yes<br class="">


QuasiQuotes: yes</div>


<div class=""><br class="">


</div>


<div class=""><br class="">


<b class="">Other<br class="">


=====</b><br class="">


<br class="">


Unsafe: no<br class="">


Safe: no<br class="">


Trustworthy: no<br class="">


Strict: no<br class="">


<br class="">


<b class="">Obsolete/Deprecated<br class="">


===================</b><br class="">


<br class="">


</div>


<div class="">CUSKs: no<br class="">


TypeInType: no<br class="">


MonadFailDesugaring: no</div>


<div class=""><br class="">


</div>


<div class=""><br class="">


</div>


<div class=""><br class="">


</div>


<div class="">If anything here seems contradictory, I can try to justify my answer.</div>


<div class="">My general rule was, “if it’s a battle-tested extension to the language rather than a change, and it’s reasonably google-able/popular, it’s probably fine”.</div>


<div class=""><br class="">


</div>


<div class="">Thanks,</div>


<div class="">Tom</div>


</div>


</body>


</html>