Winant thomas.win...@cs.kuleuven.be
wrote:
Hi,
My apologies for the late reply.
On 2014-04-10 17:43, Richard Eisenberg wrote:
What's the next step from your point of view? Are there unimplemented
bits of this?
We do see some bits left to implement:
* Partial pattern and expression
Great -- this agrees with the current proposal at the type level ((NEWCUSK) in
the language of #9200.)
Thanks for the quick response!
Richard
On Jun 19, 2014, at 6:00 PM, Simon Peyton Jones simo...@microsoft.com wrote:
| So in general, if there is a partial type signature, the compiler
|
So, without really trying to understand the code, what you are saying is this:
you want a finite map from RdrNames. That seems sensible enough, if the domain
elements all appear in the same scope in the Haskell source. I don't have
enough perspective to say whether a Uniquable instance is the
Without looking into the precise details, this looks dangerous to me. Why do
you want this? The danger I see lurking is that you might find two RdrNames
that give the same answer to getUnique but represent different things:
foo x = x + (\x - x) 3
I see two `x`s there that will have the same
Piggybacking a bit on Ömer's point:
It is often the case that something flies by that I can fix in a few moments
(for example, #9163) but that I have to defer until I have enough time for a
GHC hacking session. Making even a tiny patch requires that I'm up-to-date,
that my unchanged tree
I've gotten similar errors when my network connection is acting up -- I think
DocBook goes out to the web to download the schema for GHC's manual. When it
fails to find the schema, the errors below happen. Have you tried again? Maybe
the source for the schema (sourceforge, from the looks of it)
Jones simo...@microsoft.com wrote:
Seriously? you need a live internet connection to build GHC?? But yes, it
still hapopns
From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
Sent: 27 May 2014 13:05
To: Simon Peyton Jones
Cc: Austin Seipp; ghc-devs@haskell.org
Subject: Re: Ghc 7.8
Does FamInstEnv.normaliseType work for you? FamInstEnv is in the types/
directory. FamInst.tcGetFamInstEnvs may also be helpful. FamInst is in the
typecheck/ directory.
Richard
On May 25, 2014, at 12:42 PM, Conal Elliott co...@conal.net wrote:
I'm working on a GHC plugin in which I need to
The short answer here (to Is there a way to avoid the non-exhaustive
pattern-match warning?) is no, not in general. See #3927
(https://ghc.haskell.org/trac/ghc/ticket/3927).
And, after some playing around, I couldn't find a way to do this in your
specific example, either. I will say that I've
Yes, the TypeLits solver is still in early stages, but there's active work
being done to improve the situation. For better concrete syntax with Peano
naturals, I recommend the following construction:
type family U n where -- U stands for unary
U 0 = Z
U n = S (n - 1)
It works well in
of
LTZ - index xs i
LTS _ - index xs i
I offer no technique that can generalize this process, though...
Richard
On May 18, 2014, at 7:45 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
The short answer here (to Is there a way to avoid the non-exhaustive
pattern
Yuck yuck yuck -- that's what I think.
Austin's analysis below agrees with mine. The error *is* reasonable, because if
`coerce` worked in this scenario, a particularly dastardly (and very un-Lawful)
Monad instance could break type safety.
Furthermore, I think it's absolutely necessary that
This one was my fault/decision. The TH.Lib functions tend to mirror exactly the
constructors in TH.Syntax. We removed the constructors (for good reason --
predicates and types really are the same now), so I thought it best to remove
the TH.Lib function, too. In the cases where code had to be
Well, the problem isn't quite that the semicolon is expected before the second
line -- it's that the semicolon is interpreted as separating let-definitions,
not do-statements.
For example, the following works:
bar = do {let {x = 5};
return x}
Looking quickly through the TH's
a3896ab5d2dc88160f710705bf23e6e25e327da5
| Author: Richard Eisenberg e...@cis.upenn.edu
| Date: Mon Apr 28 13:33:13 2014 -0400
|
| Improve implementation of unSubCo_maybe.
|
| This is the result of an email conversation (off list) with
| Conal Elliott, who needed a stronger unSubCo_maybe
+1 from me
I’ve been meaning to say essentially the same thing as you just did. We all
seem to concentrate on *adding* things to GHC; it’s a bit refreshing to
consider *removing* something.
Echoing Austin somewhat:
- Anyone using external core is either working with an old GHC or is kludging
On Apr 25, 2014, at 4:16 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote:
Hello Richard,
On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote:
That map seems to store the set of variables during printing TH, for
the purposes of disambiguating identifiers with the same name
That map seems to store the set of variables during printing TH, for the
purposes of disambiguating identifiers with the same name but different
uniques. If blatting out a whole lot of program text, I could imagine the Map
getting somewhat sizeable.
But, it seems to only need the lookup and
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
a ~ EP b`.
I'm trying to build `co'` from `co`, which led to these questions.
So what do you think? Is there a sound coercion I can build for `co'`?
-- Conal
On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:
Hi Conal,
In your case, the `_N` on the argument
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
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
. 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
.: 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 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
: 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
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
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
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
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
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
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
, 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
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:
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,
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
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
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 _)
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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,
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
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
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
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
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 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
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
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
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
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
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
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)
#
#
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
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.
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
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
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
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
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
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
701 - 800 of 819 matches
Mail list logo
