News for hackers. Stuff that matters.
Re:Reflecting on Haskell in 2017 by nerdponx on Monday December 04, 2017 @12:10AM (#15841592)
What's the point of adding "optional" extensions, versus just incorporating them as features in later compiler versions?
Re:Reflecting on Haskell in 2017 by mrkgnao on Monday December 04, 2017 @04:48AM (#15842735)
Some extensions are considered bad ideas later, e.g. -XImplicitParams.

Some extensions can make existing code fail to compile, e.g. -XOverloadedStrings.

Some extensions are fairly specialised and their use can cause error messages that are confusing if you don't know what the extension does, e.g. -XAllowAmbiguousTypes.

Some extensions can cause certain pathological pieces of code to suddenly start behaving weirdly, e.g. if you turn on -XApplicativeDo for a type whose Applicative instance isn't lawful, but whose Monad instance is.

Of course, many, many extensions could be enabled by default without making the UX worse or restricting the set of allowed programs at all: a large section of Haskell users is likely in favour of enabling syntactic conveniences like LambdaCase or MultiWayIf, or automatic code-generation utilities like DeriveFoldable, DeriveTraversable, and so on. That's what Haskell Prime is for, I suppose.

Re:Reflecting on Haskell in 2017 by marcosdumay on Monday December 04, 2017 @11:53AM (#15845291)
And lets not forget about UndecidableInstances and its ilk, that enable amazing pieces of functionality if used well, but incredibly dangerous if you are not careful
Re:Reflecting on Haskell in 2017 by whateveracct on Monday December 04, 2017 @01:35PM (#15846260)
UndecidableInstances is actually not bad. I turn it on all the time and don't feel scared when I do. Worst-case, I write some bad instances and the compiler fails due to the recursion limit. IncoherentInstances is the one that really has no place since it can make code unsound.
Re:Reflecting on Haskell in 2017 by aetherspawn on Monday December 04, 2017 @02:26AM (#15842148)
Because sometimes you have to explore a space to figure out if it’s any good. No point arbitrarily adding stuff to the language if it doesn’t turn out to be that useful.

That’s how you end up with situations like ‘null’.

Some of these extensions are nuts, too. They can make the type system behave in ways where it basically has to multivariate solve or do things that are overly clever. You probably don’t want that most of the time..

Re:Reflecting on Haskell in 2017 by gizmo686 on Monday December 04, 2017 @12:26AM (#15841645)
Mostly politics. It is a lot easier to add opt-in features than get consensus to change the language.

Opt in extensions also allow you to avoid worrying about the longtail of backwards compatability.

Re:Reflecting on Haskell in 2017 by erik_seaberg on Monday December 04, 2017 @12:13AM (#15841605)
You might want to know which code is relying on an extension that's found to be a Bad Idea(tm) and rolled back or seriously changed.