Some of you have said that the core of the roles idea is stable. I tend to
agree with this. Roles catch legitimate type errors. Roles also catch what I'll
call latent type errors -- programming idioms that depend on a delicate,
unenforced type-level invariant (for example, that a type family ope
On Fri, Oct 11, 2013 at 7:17 PM, Mark Lentczner wrote:
> Do I read Bryan's post correctly, that 20% of packages on hackage fail to
> compile with GHC 7.8?
>
There are currently 5615 packages on Hackage.
Of those, 3443 built successfully with 7.6.3 on my test machine yesterday,
so let's call that
On Sat, Oct 12, 2013 at 8:00 AM, Simon Peyton-Jones
wrote:
>
> · **The current proposal, which I am happy with, is to *express
> the answer to this question in T’s role annotation*. There is design
> wiggle-room here:
>
> **o **If there is no user-supplied annotation, what should th
Hello,
On Sat, Oct 12, 2013 at 5:23 AM, Joachim Breitner
wrote:
>
> > Moreover, I'm very keen to give a simple, precise answer to the question
> > if s is coercible to t
> > when is (T s) coercible to (T t)
> > I propose that the answer is given by precisely T's roles. At the
> > mo
Hi,
Am Samstag, den 12.10.2013, 12:12 + schrieb Simon Peyton-Jones:
> The exact rules you suggest for when "deriving(Coercible)" would be
> allowed, are the rules we can use for when we need a "from thin air"
> instance.
right! The important difference is that with deriving, only the the type
I don’t really agree. Here's why:
The exact rules you suggest for when "deriving(Coercible)" would be allowed,
are the rules we can use for when we need a "from thin air" instance.
Moreover, I'm very keen to give a simple, precise answer to the question
if s is coercible to t
wh
I think perhaps we are going a bit overboard here! Some thoughts:
* Coercible is an experimental feature. If you don't use it, it won't
hurt you. I don't think there is anything wrong with having signposted
experimental features in a released compiler. And there is some merit: we wil
It's in the nature of type systems that as well as excluding bad programs they
also exclude some good programs. So if we tighten up the type system (and GND
allows seg-faults at the moment) that is certain to exclude some good programs.
Would you like a flag to say "allow me to use GeneralisedNe
Hi,
the recent discussion about roles and abstraction lets me wonder whether
we should re-evaluate the question of where the Coercible instances come
from.
Currently, upon use of "coerce", GHC will create Coercible instances out
of thin air, as long as the roles agree, and checking some
construct
Hi all,
On 2013-10-12 11:15, Herbert Valerio Riedel wrote:
Hello Simon!
On 2013-10-11 at 12:59:07 +0200, Simon Marlow wrote:
[...]
This is great. With a bit of extra tool support for this we could
actually do without submodules and go back to individual
repos. Checking out a GHC revision in
Hello Simon!
On 2013-10-11 at 12:59:07 +0200, Simon Marlow wrote:
[...]
> This is great. With a bit of extra tool support for this we could
> actually do without submodules and go back to individual
> repos. Checking out a GHC revision in the past could consist of
> querying your ghc-complete r
Hi,
Am Freitag, den 11.10.2013, 22:19 -0400 schrieb Richard Eisenberg:
> 2. Like #1, but disallow Coercible. This way, the abstraction problem
> is no worse than it was before. (Apologies to Joachim if he minds this
> suggestion.)
I don’t mind it; after all I was reluctant to put Coercible in 7.8
Hello Bryan,
On 2013-10-11 at 20:27:08 +0200, Bryan O'Sullivan wrote:
[...]
> For packages that are listed in blue, the versions that are breaking are
> the latest available. I've CCed the authors of said packages on this email.
> Folks, please fix your stuff!
btw, is there somewhere some wiki-
13 matches
Mail list logo
