Pretty random idea: What if ghc exposed measurement points for
performance and telemetry, but a separate tool would handle the
read-out, configuration, upload etc. That would keep the telemetry from
being built-in, while still being a way to get *some* information.
Such a support tool might
It could tell us which language features are most used.
Language features are hard if they are not available in separate libs.
If in libs, then IIRC debian is packaging those in separate packages,
again you can use their package contest.
What in particular makes them hard? Sorry if this
But you are right that when the programmer sits there and waits for a
result, that’s when snappyness is important.
I had a random idea based on this observation:
(With a certain flag set) the compiler could follow the existing
strategy until it has hit the first n errors, possibly with n=1.
On 2016-11-25 12:11, Simon Marlow wrote:
We basically have two worlds: first, the compile-time world. In this
world, we need all the packages and modules of the current package
built for the host platform. Secondly, we need the runtime world, with
all the packages and modules of the current
On 2016-09-28 04:06, Richard Eisenberg wrote:
+1 on `stock` from me. Though I was all excited to get my class next
semester jazzed for PL work by explaining that I had slipped a new
keyword `bespoke` into a language. :)
Maybe there's still a spot you can slip it in, e.g. bespoke error
