There's been lots of exciting work going into the forthcoming GHC 7.8.1
release. But even with all these new features, our language is far from
complete and I wouldn't want the GHC team to rest on their laurels.
Especially with so much renewed community involvement in GHC
development, it seems
On 6/27/13 8:37 AM, AntC wrote:
Folks, I'm keenly aware that GSoC has a limited timespan; and that there
has already been much heat generated on the records debate.
Perhaps we could concentrate on giving Adam a 'plan of attack', and help
resolving any difficulties he runs into. I suggest:
Adam
On 1/14/13 2:42 PM, Johan Tibell wrote:
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi sanzhi...@gmail.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
have newtype X = X Y coercing Set X
On 12/14/12 9:44 AM, Simon Peyton-Jones wrote:
This thread has made it clear that we should do more to help people
find a way in to GHC. Here is what I have done:
·Started a GHC Reading List page
http://hackage.haskell.org/trac/ghc/wiki/ReadingList, giving
background reading. It's just a
On 6/27/12 6:06 PM, Johan Tibell wrote:
This is not a theoretical issue. We have had all of the following
problems happen in the past due to the current process:
* patches never making it upstream
* releases of libraries without knowledge of the maintainer (who
finds out by finding a new
The discussion on records has in some ways narrowed (which is good), but
within that narrowed scope of disagreement become very contentious on
global vs. local default scope for field names. Those in favor of
information-hiding as a key feature have been pretty vocal so far, and
while others
On Jan 2, 2012, at 8:05 PM, Iavor Diatchki wrote:
Hello,
On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
·I don’t know exactly what you have in mean by “the ability to
reflect the type-level string at the value level”.
This can be done using
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either, perhaps it isn't *that* important to anyone. That said, it clearly
is
This post is in literate Haskell. It describes how certain performance leaks
are introduced in type level programming. These leaks do not affect program
runtimes, but can cause compile times to grow drastically. They exist both with
Functional Dependencies and Type Families, but are currently
