On Feb 6, 2013, at 1:03 PM, Gabor Greif wrote:
On 2/5/13, Richard Eisenberg e...@cis.upenn.edu wrote:
My argument would be not to return
Maybe (SameSing kparam a b)
but to return
Either (SameSing kparam a b) (SameSing kparam a b - Void)
or something similar. (Void is taken from
,
this is a library-only issue, the branch is in libraries/base, thus
somewhat tied to the 7.8 release.
Cheers,
Gabor
On 2/7/13, José Pedro Magalhães j...@cs.uu.nl wrote:
On Wed, Feb 6, 2013 at 7:17 PM, Gabor Greif ggr...@gmail.com wrote:
On 2/6/13, Richard Eisenberg e...@cis.upenn.edu
Message-
| From: ghc-commits-boun...@haskell.org [mailto:ghc-commits-
| boun...@haskell.org] On Behalf Of Richard Eisenberg
| Sent: 12 February 2013 04:10
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Fix Trac #7681. (7b098b6)
|
| Repository : ssh://darcs.haskell.org
I'm not sure if it completely solves your problem, but have you looked into
stow (http://www.gnu.org/software/stow/)? Using stow, you install an
application into a directory under ~/local/stow (using, say, ./configure
--prefix=…) and then the stow executable places symlinks to all of that
I, too, had this problem, saying /usr/bin/gcc could not execute on a Mac. gcc
was indeed there and could run just fine. Even more oddly, when I tried `make`
again, compilation would get past the point it was stuck only to fall over
again several files later. I probably could have gotten
Hi Gabor,
I can't comment specifically on your code, because I'm afraid I don't
understand it all. But, I think I can answer your question:
GHC will select a type instance branch to use in a given type family
application if and only if the following 2 conditions hold:
1. There is a
I have Mountain Lion (10.8.2, to be exact) with XCode 4.6 installed, and I can
build GHC. I don't use XCode when building, but I believe the command-line dev
tools (like gcc) are shipped with XCode, so that might be something to look at.
Sorry I don't have any more suggestions!
Richard
On Mar
On HEAD, commit b9d53..., a freshly built ghc-stage2 can't find its Prelude:
rae:22:06:54 ~/temp ~/Documents/ghc-baseline/inplace/bin/ghc-stage2
Scratch.hs
Scratch.hs:1:1:
Could not find module ‛Prelude’
There are files missing in the ‛base’ package,
try running 'ghc-pkg
Yep. That change did it.
My Makefile-fu isn't quite strong enough to feel comfortable changing the build
process, but perhaps someone should take a look at this, because I doubt I'm
the only one who would have the problem.
Thanks, Edward!
Richard
On Mar 26, 2013, at 10:48 PM, Edward Z. Yang
For more immediate satisfaction (i.e., before we get around to updating GHC in
the manner suggested on the wiki page), you have to use a parameterized type
and then specialize it to *:
data Prom2 a = Typic a
Now, we have (Prom2 * :: BOX) with (Typic Int :: Prom2 *).
Unfortunately, we have no
Hi all,
Combining ideas from a number of people/threads (Proxy and new-typeable [on
libraries] and RFC: Singleton equality witnesses [on ghc-devs]), I propose
this:
module GHC.TypeReasoning where
data a :~: b where
Refl :: a :~: a
-- with credit to Conal Elliott for 'ty' and Erik
Hi all,
GHC doesn't allow type families to be used with polytypes:
1) The right-hand side of a type family instance cannot have a forall.
2) A type family cannot be applied to a type containing a forall.
3) A pattern in a type family instance is (oddly) allowed to contain forall,
but this is
On Apr 3, 2013, at 3:01 PM, Gabor Greif ggr...@gmail.com wrote:
What I want is a function that can e.g. create the minimal union of
two Symbol singletons, possibly by consulting decidable (in)equality:
{{{ (sketch)
type family MinUnion (a :: Symbol) (b :: Symbol) :: [Symbol]
type
I'm not sure the use case being discussed here is really what I'm after. This
use case has a type family application appearing within a forall
Maybe (forall a. F [a]) ...
This actually seems to work OK when I test it, though I haven't looked closely
at the internal machinery.
I'm more
Hi all,
---
tl;dr: cabal fails to install a package where one module in the package uses
another module via Template Haskell, requiring a .dyn_o file. The compilation
order, though, makes .o files before .dyn_o files, so installation fails. Is
this my fault or cabal's?
---
I've built and
+1 to this idea. It could also identify branches which are no longer active and
perhaps can be deleted.
On Apr 11, 2013, at 3:11 PM, Nicolas Frisby wrote:
I'd like a wiki page that briefly explains the git branches.
1) Does it exist? My search for it failed.
2) Should it exist?
On Apr 16, 2013, at 3:43 AM, Christian Maeder christian.mae...@dfki.de wrote:
What is the exact command to get the relevant ghc sources.
First, make sure that your installed GHC is *not* a snapshot distribution, but
one of the main releases (such as 7.6.1 or 7.6.2). You may also want to
library
branch: https://github.com/ghc/packages-base/tree/data-proxy
Some code (and lots of documentation) is still missing; feel free to help!
Cheers,
Pedro
On Fri, Apr 12, 2013 at 2:01 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
I have updated the wiki page at
http
Hi fellow devs,
Do any of you use github for browsing the GHC code? I find it useful sometimes,
especially when I'm collaborating with someone remotely and wish to send a link
to some code, or when I don't have a particular branch to hand. As of October,
github now renders all .lhs files as
Hello all,
I recently posted a bug report about cabal that's exposed by its interaction
with GHC HEAD, and one of the cabal devs reasonably asked about a snapshot of
HEAD somewhere. The link from http://www.haskell.org/ghc/download leads to an
empty directory. Is there another place I can
Hi all,
I've implemented the proposal at
http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity, which
involved a few changes to HsDecl datatypes (FamilyDecl, TyFamInstDecl,
etc.), thus requiring a change to Haddock. I tried to be as minimal as I
could there, but prudence tells me I
-Original Message-
From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-
boun...@haskell.org] On Behalf Of Mateusz Kowalczyk
This means your GHC is too old. Compile from git and try again.
I don't think that's it -- I merged with HEAD this morning.
Out of interest, can you post a
Hi Joachim,
A few responses to your plan:
- I think you *do* want HsExprs not CoreExprs. Though I haven't worked
much in TcDeriv myself, I imagine everything uses HsExprs so that they
can be type-checked. This allows nice error messages to be reported at
the site of a user's deriving
On 2013-07-23 08:21, Joachim Breitner wrote:
Hi Richard and Simon,
thanks for your detailed notes.
Am Montag, den 22.07.2013, 17:01 +0100 schrieb Richard Eisenberg:
- I think you *do* want HsExprs not CoreExprs. Though I haven't worked
much in TcDeriv myself, I imagine everything uses HsExprs
You're right, of course. I'm now thinking we really do need ~R# to make
this work. That's annoying, but not technically difficult. I'll continue
to think about this.
Richard
On 2013-07-23 10:00, Joachim Breitner wrote:
Hi,
Am Dienstag, den 23.07.2013, 09:51 +0100 schrieb Richard Eisenberg
My fault -- sorry. Forgot to push the change to haddock when I pushed
base.
Update your haddock, and you should be OK.
Richard
On 2013-07-24 13:10, Simon Marlow wrote:
A validate today on x86_64/Linux is failing with
haddock: internal error: synifyKind
While haddocking the base package.
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 23 July 2013 15:12
| To: Edward Kmett
| Cc: José Pedro Magalhães; Dimitrios Vytiniotis; Simon Peyton-Jones;
Stephanie
| Weirich; josepedromagalh...@gmail.com; librar...@haskell.org; Conor
types declared as instances of Typeable at the place that
Typeable class is defined; no harm in one more.
So I'd really prefer the re-jig if that's ok
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 24 July 2013 22:37
| To: Simon Peyton-Jones
I haven't played much with instances, but it looks to me like
tcInstDecls1, in typecheck/TcInstDecls.lhs, is a good place. Toward the
end of the body of that function is a bunch of checks in the style that
you will need to write (such as for bogus Typeable instances).
I hope this helps!
Hi Joachim,
As discussed previously, I do think we need a way to store representational
coercions. In my roles branch (which is getting close to pushing, I believe), I
have created eqReprPrimTyCon, which is like eqPrimTyCon, but it is the type of
coercions witnessing representational equality.
Thanks for the heads up. I did indeed not push libraries/Cabal, because
I thought it would go along with pushing ghc. (I find git submodules to
be rather confusing.) I've now pushed, but to
darcs.haskell.org/srv/darcs/libraries/Cabal, which I believe is the same
place. Please try again and let
After the libffi-tarballs submodule was added, I did a ./sync-all pull,
a ./sync-all get, and a git submodule update. Everything builds just
fine, but I get this answer from git status:
# On branch master
# Untracked files:
# (use git add file... to include in what will be committed)
#
#
OK -- the page is up at http://ghc.haskell.org/trac/ghc/wiki/Newcomers
Please improve it as you see fit!
Richard
On 2013-08-06 07:04, Vincent Hanquez wrote:
On 08/05/2013 10:51 AM, Richard Eisenberg wrote:
I think a hacking session is a great idea, either over IRC or at ICFP.
I'm also
.
And as an aside question, when would one need to compile state 1 vs
stage 2 (aside from the first compilation)?
On Fri, Aug 9, 2013 at 6:56 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:
OK -- the page is up at
http://ghc.haskell.org/trac/ghc/wiki/Newcomers [1] Please improve
it as you see fit
Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if
EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to make
sure that we're conforming to the Haskell standard. But, if the user has
specified EmptyDataDecls, then we're not bound to that requirement
with your reasoning here.
It's more consistent to have it apply to all of the base classes which
are derivable.
On Sun, Aug 11, 2013 at 9:14 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if
EmmptyDataDecls is specified. The reason
Yay! I'm really excited to see this coming along so nicely, especially as it
has such a nice interaction with roles.
Here are some specific thoughts, upon reviewing your (surprisingly short!)
patch:
- I strongly dislike the name NT (and derivatives), for at least two reasons:
1) Someone new
On Sep 6, 2013, at 12:47 PM, Simon Peyton-Jones simo...@microsoft.com wrote:
So
* for newtypes
newtype N a = MkN rep-ty
the coercion is between (N a) and its representation type rep_ty.
The coercion is allowed if the data constructor MkN is in scope
* for data types (T a),
OK -- thanks for clarifying. This all sits better with me.
But, I'm still a little concerned about the Safe Haskell implications. My
understanding is that allowing coercions when the constructor is not exported
will not be considered Safe. Here's a way forward:
Currently: a type is considered
On Sep 8, 2013, at 7:27 PM, Austin Seipp ase...@pobox.com wrote:
* Pedro and Richard - what's the story on propositional equality,
etc? This is mentioned on the status page[1] but I'm not sure what
else needs to be done. I know Pedro committed the work to make manual
Typeable instances an
page, Joachim.
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 07 September 2013 18:46
| To: Simon Peyton-Jones
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: newtype coercion wrapping status
|
| OK -- thanks for clarifying
I took a look here and would like to help, but I'm confused: What makes you
think the dictionary for (Eq [b]) would be in scope? I can see where the (Eq b)
comes from (the theta that pops out of patSynSig), but where does (Eq [b]) come
from?
Richard
On Sep 8, 2013, at 4:31 AM, Dr. ERDI Gergo
Hi devs,
I'm in the process of reimplementing role annotations (#8185). I need to add a
new pseudo-keyword 'role' to the lexer, and I'm initially tempted to guard the
lexing of this keyword with an extension bit (like, say, tyFamBit in Lexer.x).
But, there are already bits 0 to 31 taken, and
Very cool!
In the feature as pushed, is it possible to use coerce on any old newtype? If
so, then it really is a language feature and probably should go into the
manual, if `coerce` is exposed.
What was the end result of the discussion on abstraction? Can a library control
how its types are
plenty
of magic stuff like unsafePerformIO, unsafeCoerce, or StableNames,
which are not documented in the manual.
Just curious.
Roman
* Richard Eisenberg e...@cis.upenn.edu [2013-09-15 16:48:16-0400]
Very cool!
In the feature as pushed, is it possible to use coerce on any old newtype
On Sep 15, 2013, at 5:44 PM, Joachim Breitner m...@joachim-breitner.de wrote:
not really; if you type :info Coercible you see that there are no
instances created. Just the type-checking of uses of coerce is a bit
special.
Even stranger, I think. I understand that there aren't really any
to send a link, even just to a file on github -- I hate
repeating myself about these things, too!
On Sep 15, 2013, at 5:13 PM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
Am Sonntag, den 15.09.2013, 16:48 -0400 schrieb Richard Eisenberg:
What was the end result of the discussion
Hi David,
Joachim, Simon, and I have been trying to figure out how roles and newtype
coercions fit in with Safe Haskell. (See, for example
http://www.haskell.org/pipermail/ghc-devs/2013-September/002526.html, which I
will try to summarize here.)
It all boils down to this: Does Safe Haskell
In light of the conversations I've been having with Edward and others, I, too,
wonder if we should wait a little before doing this. There is no burning fire
here. Though we have Coercible in 7.8, that doesn't mean we *have* to use it.
The old trick to use unsafeCoerce in the situations Edward
I'll take a look at the roles failures. It would be helpful to know if we've
found bugs in libraries' code or if this is just the no-role-polymorphism
problem.
On Oct 1, 2013, at 4:13 AM, Simon Peyton-Jones wrote:
Bryan
That’s amazingly helpful thank you.
I undertake to fix the
Sorry if this has been addressed recently, but I can't validate right now, due
to a build failure from -Werror in C code in primitive:
inplace/bin/ghc-stage2 -optc-Werror -optc-Wall
-optc-Ilibraries/primitive/cbits -optc-O3 -optc-ftree-vectorize
-optc-fomit-frame-pointer -optc-msse2
Done. Thanks for setting this up!
On Oct 8, 2013, at 4:01 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
Hi all,
I created a wiki page that gathers useful Emacs configuration:
http://ghc.haskell.org/trac/ghc/wiki/Emacs
My intention for this page was to be as self contained as possible,
Is there a way to get back the preview window as I'm writing a comment on a
ticket? Perhaps I'm just missing the button somewhere, but I liked that window!
Thanks!
Richard
On Oct 6, 2013, at 9:02 AM, Herbert Valerio Riedel h...@gnu.org wrote:
Hello *,
The Trac instances at ghc.haskell.org
For future reference (my own future reference, most likely), here are why these
packages break:
On Sep 30, 2013, at 2:26 AM, Bryan O'Sullivan wrote:
12 language-c-0.4.2the last parameter of ‛Error’ is at role Nominal
Legit error. The Error class has Typeable as a superclass, and using
PM, Richard Eisenberg e...@cis.upenn.edu wrote:
In Bryan's recent test of GHC 7.8 against all of Hackage, there were three
spurious errors caused by lack of role abstraction. Here are the class
definitions where a nominal parameter is inferred, probably against the
wishes of the author
in the current solution I fear we'll get stuck in a local optimum,
with a much better solution just over the hill.
-Edward
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
Eisenberg
Sent: 12 October 2013 03:20
To: Edward Kmett
Cc: Stephanie Weirich; Joachim Breitner; ghc
Yuck.
But, many, many thanks for discovering this now instead of later.
For various silly reasons, I didn't have a platform (i.e. a recent enough HEAD
in the right state, etc.) for me to explore this today (Monday). But, I should
have the time and ability to look closer on Tuesday.
If it's
Please see my responses below. (Note: this was written before Edward's most
recent post, which will be addressed shortly.)
Executive summary: Edward's problem is more general than the one that Simon
solves, but what Edward wants is actually not type safe.
On Oct 16, 2013, at 9:28 AM, Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward
Kmett
Sent: 13 October 2013 23:02
To: ghc-devs; Richard Eisenberg
Subject: Re: More GND + role inference woes
I didn't think I was using GND much at all, but apparently I was wrong.
After Ben's initial
On Oct 16, 2013, at 1:46 PM, Edward Kmett wrote:
Off the top of your head do things like the following work under the new
scheme?
newtype T m a = T { runT :: StateT MyState m a } deriving (Monad, MonadState
MyState, MonadTrans)
Yes, I believe that will work. The only hard part is for
. Not sure exactly how hard it will be.
Richard
Simon
From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
Sent: 16 October 2013 18:29
To: Simon Peyton-Jones
Cc: Edward Kmett; ghc-devs
Subject: Re: More GND + role inference woes
Please see my responses below. (Note: this was written
Hi all,
The implementation of the new GND check is done and was rather straightforward.
But, it brings up a new design issue: With the old check, a writer of a class C
could say `type role C nominal` to prevent GND use with that class. Now, all
classes have nominal parameters, and there is no
been.
Thanks,
Richard
On Oct 22, 2013, at 4:50 AM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
Am Montag, den 21.10.2013, 13:08 -0400 schrieb Richard Eisenberg:
For the curious, you can see the code in my github fork
at
https://raw.github.com/goldfirere/ghc/master/compiler/typecheck
Hi all,
The recent spate of commits that I've pushed change the default roles assigned
to classes. Accordingly, I also changed the filter used within ghci only to
print out role information when it differs from the default. However, if you've
incorporated my commits but haven't updated your
Bah. This is a bug. I will fix.
Thanks for pointing it out!
Richard
On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka r...@ro-che.info wrote:
* Richard Eisenberg e...@cis.upenn.edu [2013-10-16 13:28:54-0400]
Moreover, I think this solves the other failures in
http://www.haskell.org/pipermail/ghc
Roles makes GND completely type-safe. You cannot make unsafeCoerce using GND.
However, you can look around abstractions with GND, both before and after roles
-- roles weren't really designed to stop you from doing this. See #5498.
Whether this is grounds to make GND unSafe is up to the
Bah^2.
This is subtler than I thought.
See the ticket commentary here: http://ghc.haskell.org/trac/ghc/ticket/8503
Richard
On Nov 4, 2013, at 11:02 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
Bah. This is a bug. I will fix.
Thanks for pointing it out!
Richard
On Nov 4, 2013, at 10
I'm unaware of any progress on this front since the thread died out. I don't
really think I have time to get too involved in an answer, but I'd be quite
keen to hear of one!
Richard
On Nov 11, 2013, at 2:47 PM, Nicolas Frisby wrote:
Has there been any other discussions/write-ups regarding
Hi Simon, Joachim, and others,
I'm in the midst of reimplementing GeneralizedNewtypeDeriving in terms of
coerce. See #8503 for why I'm doing this. But, I've run up against a limitation
of Coercible I'd like to know more about. Currently, the stage2 compiler fails
to build because of the
want to unpack infinitely. Strictness analysis also risks
infinitely unpacking a strict argument.
I think the rules for newtypes could be different (and perhaps more generous)
than for data types.
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e
Hi devs,
I happened to be looking through the code dealing with known names, and I'm a
little confused about templateHaskellNames. In particular, I'm confused why
it's included in knownKeyNames only when GHCI is defined. (See lines 196-198 of
HscMain.) It's the stage 1 compiler that compiles
Yes, I believe that's right. As far as I can figure out, these classes really
*are* problematic, in that if we allowed GeneralizedNewtypeDeriving for them,
there would be a way to subvert the type system. To make these derivable, we
would need to be able to restrict various type parameters from
On Dec 14, 2013, at 7:59 PM, Ben Gamari wrote:
I suppose it's unlikely that the roles mechanism will be extended to
allow for such restriction?
Very unlikely in the short term. As more use cases for such a feature filter in
and the community demands the feature, there's no strong technical
As someone CC'd on this email directly, I'll answer for myself: While I've
benefited from the delay to fine-tune the behavior of certain bits bobs, I
didn't request the delay nor do I believe myself responsible for generating or
needing to fix any blocking feature. Please correct me if I'm
Hi Gergo,
As pattern synonyms are user-facing, you should update the user manual along
with (perhaps) the wiki. The file to edit is docs/users_guide/glasgow_exts.xml.
You should also add a note to docs/users_guide/7.8.1_notes.xml.
Apologies if someone has already said this to you.
Richard
On
Maybe I'm missing something here, but how does specifying TypeHoles make GHC
not compliant with Haskell 2010? Turning on TypeHoles should change only error
messages. The set of programs that compile (and their meanings) should remain
unchanged, by my understanding.
I'm mildly in favor of this
Let me take a different slice at this question, inspired more by Joachim's
subject line than his text: On a number of occasions I've wanted to write unit
tests against a certain function or set of functions. The role inference
algorithm is a prime example, but it's happened elsewhere, too. The
Yay!
I, for one, would probably submit more bugfix patches with this structure in
place. I take validating seriously, but my daily schedule often involves
switching machines and tasks, and once I press validate, it's often hours
before I actually look at the results... by which time, some
Say I have
data Nat = Zero | Succ Nat
data SNat :: Nat - * where
SZero :: SNat Zero
SSucc :: SNat n - SNat (Succ n)
data SBool :: Bool - * where
SFalse :: SBool False
STrue :: SBool True
Now, I want
eq :: SNat a - SNat b- SBool (a == b)
eq SZero SZero = STrue
eq (SSucc _)
One potential source of confusion in this thread:
When Adam initially suggested a function (Constraint - Maybe String), I
believe he was referring to constraints as they slosh around within GHC, *not*
the kind-level Constraint available with ConstraintKinds. So, the
error-reporting function
little tweaks
like this might make sense. Richard Eisenberg and I were discussing this
earlier, and we wondered if the following might provide an alternative
approach:
Suppose a module provides a function
describeError :: Constraint - Maybe String
(exact type up for discussion
My question is: why do you want Eff to be a GADT? It's true that GADTs do not
promote (currently), which is why your first example doesn't work. (It's not to
do with kinds, exactly, but GADTs.) But, I don't quite see a reason for having
a GADT there -- generally, when a GADT is really useful,
I think those should be the same and that you've discovered a bug. What's the
definition of the Parsing class?
Thanks!
Richard
On Mar 5, 2014, at 3:28 PM, Sergei Trofimovich wrote:
Hello!
Trying to build random packages with fresh ghc-7.8.1-rc2
I've come up with a strange bit:
, Sergei Trofimovich sly...@gmail.com wrote:
On Wed, 5 Mar 2014 15:40:27 -0500
Richard Eisenberg e...@cis.upenn.edu wrote:
I think those should be the same and that you've discovered a bug. What's
the definition of the Parsing class?
Here it goes [1]:
class Alternative m = Parsing m where
Note that the removal of `classP` is only for HEAD -- it will *not* be merged
in for 7.8, which would be way too big a change at this point.
Richard
On Mar 22, 2014, at 4:53 PM, Mateusz Kowalczyk wrote:
On 22/03/14 20:37, Johan Tibell wrote:
What's the right way to fix libraries (e.g. aeson)
On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
Is there a reason why the Template Haskell version wasn't bumped
after this change?
No -- I just didn't think of it. I won't have time in the next few days to do
this (and validate, etc.), but I'll make this change soon.
Thanks,
Richard
Thanks, Herbert. I'll cross this off my to-do list.
Richard
On Mar 23, 2014, at 5:37 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote:
On 2014-03-23 at 04:40:14 +0100, Richard Eisenberg wrote:
On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote:
Is there a reason why the Template Haskell
I have a few responses to various themes in this thread, but nothing terribly
unexpected:
- The introduction of roles is the end of the story that began with the
discovery of bug #1496. The alternative would be to do away with GND. `coerce`
is just a convenient application of roles, not the
Hi Mark,
I appreciate your analysis in terms of classes of users -- I think that is
helpful for framing the discussion.
About transitivity: I think we're in the clear here. Let's say package A
exports types missing role annotations. If package B imports package A and
wants to have the full
is already
thinking about restricting how the type is used.
Not that I'm really even suggesting such a rule, just wondering if it
was discussed.
- C.
On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
Hi Mark,
I appreciate your analysis in terms of classes
Did you `./sync-all get`? Did you `perl boot`? You may want to check out the
Building GHC section of https://ghc.haskell.org/trac/ghc/wiki/Building to
make sure you've followed all the steps.
I hope this helps,
Richard
On Mar 27, 2014, at 6:27 AM, Maarten Faddegon ghc-...@maartenfaddegon.nl
on the Getting the GHC Sources-page
and because I rather make my changes to an otherwise stable tree. Do you
think this is a bad idea?
Cheers,
Maarten Faddegon
On 27/03/14 11:41, Richard Eisenberg wrote:
Did you `./sync-all get`? Did you `perl boot`? You may want to check out
: If
the default changes, and my GND library breaks, all my users are broken, and
worse, I can't do anything about it until I compel the libraries I depend on
to annotate.
This is why we can't ever change the default.
On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg e...@cis.upenn.edu wrote
I spent some time thinking about what, precisely, can be done here to make
folks happier. (See the thread beginning here:
http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the
answer seemed to all be in the concrete syntax. The only logical alternative
(that I could think
.: The above is based on a limited understanding of the problem, so
I'm sorry if it misses some aspect of the problem...
2014-03-31 2:14 GMT+02:00 Richard Eisenberg e...@cis.upenn.edu:
I spent some time thinking about what, precisely, can be done here to make
folks happier. (See the thread
. I would fancy that
this not-quite-as-safe GND could use unsafeCoerce wherever the safe
one would give an error about annotated roles.
Regards,
Dominique
2014-03-31 17:05 GMT+02:00 Richard Eisenberg e...@cis.upenn.edu:
Hi Dominique,
When implementing roles, I was indeed worried about
17:05 GMT+02:00 Richard Eisenberg e...@cis.upenn.edu:
Hi Dominique,
When implementing roles, I was indeed worried about the problem you're
addressing: that code that previously worked with GND now won't. However,
it turns out that few people have really complained about this. IIRC, in
all
Yay!
I have nothing else constructive to say, at the moment.
What's the next step from your point of view? Are there unimplemented bits of
this?
Thanks for doing this!
Richard
On Apr 10, 2014, at 3:48 AM, Thomas Winant thomas.win...@cs.kuleuven.be wrote:
Hi,
I'm back with a status
I agree with Simon, but just `Sub` the `LambdaCCC.Lambda.EP_N`, not the whole
coercion.
There are actually two problems here. The one Simon identified, and also the
fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I
know? Because of the `NT` -- it's a newtype axiom
the entire coercion (applying `mkSubCo
. mkAppCo (Refl Nominal ep)`), and I see the same result:
(LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] GHC.Types.Bool_N)))_R
-- Conal
On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
I agree with Simon, but just `Sub
1 - 100 of 819 matches
Mail list logo
