HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nick8325
quickspec
Haskell2016–2016
nick8325 / quickspec

quickspec

Equational laws for free

2Distinct people
2Mentions
0Explicit recommenders
272GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Equational laws for free

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:19:25 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month2 dated mentions

Observed mentions: 2016-02-16 08:07:05 UTC to 2016-11-29 20:54:35 UTC.

012016-02-01 00:00:00 UTC to 2016-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 20162016-03-01 00:00:00 UTC to 2016-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-04-01 00:00:00 UTC to 2016-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-05-01 00:00:00 UTC to 2016-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-06-01 00:00:00 UTC to 2016-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 20162016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-11-01 00:00:00 UTC to 2016-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsNov 2016

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 20162016-02-01 00:00:00 UTC2016-03-01 00:00:00 UTC101
Mar 20162016-03-01 00:00:00 UTC2016-04-01 00:00:00 UTC000
Apr 20162016-04-01 00:00:00 UTC2016-05-01 00:00:00 UTC000
May 20162016-05-01 00:00:00 UTC2016-06-01 00:00:00 UTC000
Jun 20162016-06-01 00:00:00 UTC2016-07-01 00:00:00 UTC000
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC000
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC000
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC000
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC000
Nov 20162016-11-01 00:00:00 UTC2016-12-01 00:00:00 UTC101

What Hacker News says

1 sources
Just watched the talk. The technique the author's discovered is called "supercompilation" (note: this is distinct from "superoptimisation", mentioned in sibling comments). The idea is to use an evaluation strategy which works at compile time, reducing statically-known expressions whilst shuffling around unknown values symbolically to preserve the semantics. The result ends up folding constants, inlining, unrolling, etc. automatically, just like the examples in the talk. Whilst supercompilation can be slow, the main criticism is that resulting code is quite large, due to the amount of inlining. The main difference between supercompilers and the technique discussed in the talk is that supercompilation is provably correct: it doesn't rely on testing or placing exhaustiveness requirements on the user. I don't think it's necessary to sacrifice
Read the rest
correctness; the speaker mentioned the use of guards in JITs, and how he avoids them for speed, but I think that since we're performing such extensive rewriting of the code anyway, many redundant guards can be supercompiled-away, and those remaining can be shunted to the start of the program, so that no branches appear in the hot path. The allusions to the scientific method seem to be about properties/invariants, and potential counterexamples to them. I'm all for finding and sharing properties of programs, both conjectured and proven, although I don't like the idea of assuming the conjectures are true. I've looked into this in Haskell, and found some great work, including: - QuickSpec (v1 https://hackage.haskell.org/package/quickspec and v2 https://github.com/nick8325/quickspec ) which conjectures equations about functions by testing them on random inputs. - HipSpec ( https://github.com/danr/hipspec ) which does the same as QuickSpec, but automatically proves the equations so they're guaranteed to hold. - The GHC compiler's rewrite rule system ( https://wiki.haskell.org/GHC/Using_rules ) which allows programs to be optimised by replacing regular definitions with optimised versions in particular cases. This is how "fusion" and "deforestation" optimisations are implemented, e.g. https://donsbot.wordpress.com/2010/02/26/fusion-makes-functi... I think there's definitely some low-hanging fruit there, for finding equivalent expressions, comparing their performance, and generating a list of rewrite rules which the programmer may want to consider adding to their code. A slightly more ambitious project would use equations/properties about the program to generate a specialised supercompiler (maybe using something like a variant of knuth-bendix completion, ordered such that the normal forms are the higher-performing variants).
In Beating the Compiler

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.