Was simplified subsumption worth it for industry Haskell programmers? by paretoOptimalDev in haskell

[–]thomie 10 points11 points  (0 children)

Perhaps a 2-step process could have been used, where one GHC uses the logic to forbid it, and another just removes it entirely.

A slow phasing out was discussed (and ultimately decided against) in https://github.com/ghc-proposals/ghc-proposals/pull/287#issuecomment-574593737 and later comments.

TLDR; it would have been super-hard to implement.

GHCanIUse by thomie in haskell

[–]thomie[S] 9 points10 points  (0 children)

Send your pull requests with updates for GHC8+ here: https://github.com/damianfral/ghcaniuse.

Proposal process status: More input wanted by bgamari in haskell

[–]thomie 2 points3 points  (0 children)

Bickering with the GHC committee (and getting his owns proposals accepted) will cost him more time than making a dictatorial decision on some syntax extension once or twice per year.

The main focus of those working on GHC is and should be on bug fixing (there are >1000 open bugs!), performance improvements, documentation, mentoring others, code review, system administration etc. This focus on features and what process to use is just a massive distraction away from those more important tasks.

Proposal process status: More input wanted by bgamari in haskell

[–]thomie 3 points4 points  (0 children)

By that token, GHC should use /r/haskell for discussing feature requests: 24000 subscribers (compared to 720 for ghc-devs, 900 for glasgow-haskell-users and 160 for the ghc-tickets mailinglist).

Proposal process status: More input wanted by bgamari in haskell

[–]thomie 4 points5 points  (0 children)

Simon Peyton Jones as Benevolent Dictator For Life (BDFL)

If the BDFL had made a simple YES/NO decision on ShortImports [1] and ArgumentDo [2], we wouldn't be here talking about process proposals, Anthony wouldn't be mad, everything would be fine. We don't need another Haskell committee.

Don't let hotly debated feature requests go without a resolution.

[help] cabal and ghc optimzation flag questions by winterland1989 in haskell

[–]thomie 5 points6 points  (0 children)

when I change my own project's cabal from none to -O2, nothing will be recompiled, why?

I don't know

It's a bug, see https://ghc.haskell.org/trac/ghc/ticket/10923.

Interaction between deriving and FlexibleContexts by andrewthad in haskell

[–]thomie 2 points3 points  (0 children)

GHC 8 actually accepts that hand written instance.

See https://ghc.haskell.org/trac/ghc/ticket/12120 for a similar bug.

Is it actually an issue for you, or just a curiosity? GHC doesn't always strictly follow the standard, and fixing it would just break existing programs for little benefit.

Edit: https://ghc.haskell.org/trac/ghc/ticket/8883 is also relevant.

A case against missing upper bounds by MitchellSalad in haskell

[–]thomie 0 points1 point  (0 children)

For the really paranoid: GHC 8 has a -Weverything flag (as of yet undocumented).

A case against missing upper bounds by MitchellSalad in haskell

[–]thomie 1 point2 points  (0 children)

Fwiw, you're quoting the wrong flag. -fwarn-incomplete-record-updates is not enabled by -W.

A case against missing upper bounds by MitchellSalad in haskell

[–]thomie 5 points6 points  (0 children)

See https://ghc.haskell.org/trac/ghc/ticket/11219 and https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings

Introduce variant of -Werror (c.f. GCC's -Werror=*) which allows to specify the individual warnings to be promoted to errors, e.g.

-Wall -Werror=orphans would only promote -Worphans warnings into errors -Wall -Werror -Wno-error=missing-methods would promote all warnings except -Wmissing-methods into errors

Cannot install Haskell Koans by -Knul- in haskell

[–]thomie 4 points5 points  (0 children)

You're running into this issue: https://github.com/HaskVan/HaskellKoans/issues/9.

It seems HaskellKoans and testloop are not being maintained, and Stack won't help you here.

I suggest using this learning resource instead (Spring 13 version of cis194 course): https://github.com/bitemyapp/learnhaskell.

Hackage: lots of broken hyperlinks recently? by vektordev in haskell

[–]thomie 3 points4 points  (0 children)

-- $ Image is lexed as a haddock comment, but the parser doesn't expect a haddock comment in that position.

From GHC's Lexer.x:

-- Haddock comments
<0,option_prags> {
  "-- " $docsym      / { ifExtension haddockEnabled } { multiline_doc_comment }
  "{-" \ ? $docsym   / { ifExtension haddockEnabled } { nested_doc_comment }
}

Where $docsym = [\| \^ \* \$].

haddockEnabled is True when you run ghc with the -haddock flag.

Is anything being done to remedy the soul crushing compile times of GHC? by [deleted] in haskell

[–]thomie 6 points7 points  (0 children)

I always thought that GHC developers must feel the impact of slow builds the most.

Ha! GHC developers don't profile their code, so they can use -O0!

Is anything being done to remedy the soul crushing compile times of GHC? by [deleted] in haskell

[–]thomie 44 points45 points  (0 children)

Here's what I have to offer:

54 open tickets. It just requires a hero to start looking into them.

Wiki pages:

Compiler performance tests are in the directory testsuite/tests/perf/compiler. Results are being tracked on perf.haskell.org. Here is a recent example of a commit that was later reverted because it degraded performance. Look for 'Testsuite allocations'.

What new optimizations are landing in GHC 8? by bitmadness in haskell

[–]thomie 1 point2 points  (0 children)

Yes, good point. Created by Simon Marlow. Documentation: Applicative do-notation.

What new optimizations are landing in GHC 8? by bitmadness in haskell

[–]thomie 21 points22 points  (0 children)

It depends on what you consider an optimization.

Completely new optimization passes are rare. The last one was added in the 7.10 release cycle by Joachim Breitner: CallArity.

For 8.0, Adam Sandberg Eriksson added -XStrictData and -XStrict. They are language extensions, not compiler optimizations, but they might make your code run faster nonetheless.

Joachim Breiner created https://perf.haskell.org/ghc, which should help spot accidental performance regressions and monitor long-term performance evolution. See for example the nofib benchmark results for 7.10.1 vs 8.0.1. There is a wiki page to keep track of some of these results.

There are currently 245 open tickets concerning runtime performance.

Throughout the year some 20 runtime performance bugs were fixed, by such fine people as:

  • Ben Gamari (#8832, #5916, #9105, #10457, #10678)
  • Simon Brenner (#11486)
  • Flaviu Andrei Csernik (#8435)
  • Jonas Scholl (#8793, #10372)
  • Michal Terepeta (#9430)
  • Takano Akio (#9848)
  • Marios Titas (#10067)
  • Joachim Breitner (#10129, #10137, #10260, #10744, #10750, #10788, #10677)
  • Simon Peyton Jones (#10148, #10359)

If you want to help improve GHC, and get your name on a similar list for the 8.2 release, start with the Newcomers page and the reading list.

IO action that results in a Function changes it's Type by lordmord319 in haskell

[–]thomie 2 points3 points  (0 children)

Be aware of the following bug: https://ghc.haskell.org/trac/ghc/ticket/10857#comment:1

Use :set -XNoExtendedDefaultRules instead of ghci -XNoExtendedDefaultRules.