Hi devs,
I've just posted #10583 (http://ghc.haskell.org/trac/ghc/ticket/10583) about
fixing up basicTypes/Lexeme.hs. As stated in the ticket, I'm happy to do the
hacking, but I need some advice. My most pressing question is this:
Examine the following functions, which all should do the same
all the
tickets”.
You could link to the page from https://ghc.haskell.org/trac/ghc/wiki/Status
Simon
From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
Sent: 26 June 2015 13:19
To: Simon Peyton Jones
Cc: ghc-devs
Subject: Re: Template Haskell working group
Hi Simon
Hi Simon,
I'm happy to take this on. Through `singletons`, I am a heavy TH user and know
that end of GHC well.
The one caveat I offer is that I vastly prefer to chunk up similar bits of
work, and generally intend to let TH tickets languish until I sweep them all
up, somewhere near the planned
type: your type, like Proxy a a' b b' m v
I would be glad if we could have an expansions enabling flag in GHC, and
could consider turning it on by default if it will look good for that.
16 черв. 2015 22:44 Richard Eisenberg e...@cis.upenn.edu пише:
GHC tries hard to preserve type synonyms
On Jun 17, 2015, at 8:00 AM, Simon Peyton Jones simo...@microsoft.com wrote:
On a fresh build of the 7.10 branch, I get five validate failures on Linux.
They are below. Is this only me?
typecheck/should_fail T10534 [stderr mismatch] (normal)
That's probably my fault. As long as
GHC tries hard to preserve type synonyms where possible, but of course, it
can't preserve all of them. The general rule it tries to follow is: preserve
vanilla type synonyms; expand type families. This is true both in expected
types and actual types.
If you have a case where you believe that
I like the general directional of travel here, with two specific points to make:
- Unlike Eric, I like embedding CoreExprs directly into EvTerms. Yes, it's a
little funny to do so before desugaring, but there's precedent for such things
(like embedding Coercions into TcCoercions and Types into
Speaking of this, is it possible to get an official build put up on the page
Andrew links to? In my opinion, we shouldn't announce a new release until
binaries are available at haskell.org for all Tier-1 platforms.
Thanks!
Richard
On Apr 22, 2015, at 5:10 PM, Andrew Farmer afar...@ittc.ku.edu
Thanks for posting the bug and bringing it to our attention. The reason the
report may not have gotten attention is that I believe this falls in Simon PJ's
domain, and he's on holiday right now. I took a quick look, but I haven't a
clue about this area of GHC, so there's not much I can
Trac is bac.
But is there anything we can do to improve reliability?
Thanks!
Richard
On Apr 16, 2015, at 10:19 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
Hi devs,
Trac isn't working again. In an entirely unscientific study, 4 out of the
last 5 sessions where I tried to access Trac
| To: Richard Eisenberg; ghc-devs@haskell.org Devs
| Subject: Re: stack traces when debugging GHC
|
| On 09/02/2015 02:51, Richard Eisenberg wrote:
| Hi devs,
|
| I've just made a miraculous discovery and I want to share!
|
| It has happened many times that I create some bizarre
On Apr 12, 2015, at 9:51 AM, David Terei dave.te...@gmail.com wrote:
Ideally I'd like to find a way forward that works for everyone and
isn't just a Safe Haskell mode setting.
Agreed. I'm not convinced this can be done, but it's certainly worth trying.
I think the first question is, are
This is now on Phab as https://phabricator.haskell.org/D757
I'll be making some comments there.
On Mar 26, 2015, at 9:23 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
I'll take a look in the next few days. I'm concerned about that performance
regression -- we'll need to get a handle
On Mar 23, 2015, at 10:58 AM, Christopher Done chrisd...@gmail.com wrote:
Someone added this text:
Many now recommend just using a bare compiler combined with sandboxed
dependencies, especially for new users. However, others prefer to
start with the curated blessed set of packages in
On Mar 22, 2015, at 9:40 PM, Brandon Allbery allber...@gmail.com wrote:
That's interesting, because http://ghcformacosx.github.io is pretty much the
only thing anyone recommends to Mac users any more, and in #haskell people
seem to actively steer everyone away from the Platform in all its
Thanks, Iavor, for doing this!
On Feb 7, 2015, at 3:11 PM, Iavor Diatchki iavor.diatc...@gmail.com wrote:
1. Add a new filed to `TypeRep` that remembers _kind_ parameters:
TypeRep Fingerprint TyCon [TypeRep]{-kinds-} [TypeRep]{-types-}
Perhaps change to use record syntax? With two
On Feb 1, 2015, at 2:07 PM, Adam Gundry a...@well-typed.com wrote:
(There is a plan to get rid of this subkinding in favour of normal
polymorphism, but it hasn't been implemented yet. See
https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds for more details.)
The NoSubKinds plan *is*
Hi devs,
I've just hit on a strange bug, and I don't know where to start looking.
In my branch where I'm building support for dependent types
(github.com/goldfirere/ghc.git; branch: nokinds but you don't need to look
there) I'm going through the testsuite and picking off bugs one at a
|
| | -Original Message-
| | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| | Manuel M T Chakravarty
| | Sent: 16 January 2015 02:58
| | To: Richard Eisenberg
| | Cc: ghc-devs@haskell.org Devs
| | Subject: Re: vectorisation code?
| |
| | [Sorry, sent from
On Jan 16, 2015, at 4:12 AM, Simon Peyton Jones simo...@microsoft.com wrote:
For 7.10, DPH is definitely not supported, I'm afraid.
Does this mean that the vectorisation code is also defunct? As in, is there a
way to usefully access the feature without DPH?
Richard
to do by any chance in 7.8.4 later?
On Tue, Jan 13, 2015 at 8:32 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
Hello Magesh,
The bug is in 7.8.3, which should never have allowed your `Test1`. Haskell
type families may not be partially applied -- the type system and type
inference just
Hello Magesh,
The bug is in 7.8.3, which should never have allowed your `Test1`. Haskell type
families may not be partially applied -- the type system and type inference
just don't know how to handle such things. In 7.8.3, the check was accidentally
turned off, as discussed in #9433, as you
Hi devs,
There's a sizable number of modules in the `vectorise` subdirectory of GHC. I'm
sure these do all sorts of wonderful things. But what, exactly? And, does
anyone make use of these wonderful things?
A quick poking through the code shows a tiny link between the vectorise code
and the
On Jan 9, 2015, at 5:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
Especially that we're talking about internal TH module - I'll be surprised if
there are more than 10 users.
As I understand it, TH.Lib is not an internal module. Though I, personally,
have never found the functions there
: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 17 December 2014 15:56
| To: Simon Peyton Jones
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| By unsubstantiated guess is that INLINEABLE would have the same effect
| as INLINE here, as GHC
For what it's worth, I don't have a strong feeling either way here.
Arguments in favor of keeping -fwarn-unticked-promoted-constructors in -Wall:
1. It's weird having GHC look in one namespace (types) and then look in
another (terms) only when the first one fails. In other scenarios, ambiguity
of calls?
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 16 December 2014 21:46
| To: Joachim Breitner
| Cc: ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| I've learned several very
On Dec 17, 2014, at 12:29 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
Why not implement repPlainTV like this: ?
repPlainTV :: Core TH.Name - DsM (Core TH.TyVarBndr)
repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm)
In short, that's ill typed. We have
newtype Core a = MkC CoreExpr
are delegated
to template-haskell
library. Couldn't all of this be done locally?
Janek
Dnia środa, 17 grudnia 2014, Richard Eisenberg napisał:
On Dec 17, 2014, at 12:29 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
Why not implement repPlainTV like this: ?
repPlainTV :: Core TH.Name
; will push when that's done.
Thanks,
Richard
On Dec 16, 2014, at 10:41 AM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg:
On Dec 16, 2014, at 4:01 AM, Joachim Breitner m...@joachim-breitner.de
wrote:
another
I've made progress, but still need some help.
It turns out that a monadic combinator (that I wrote) is mostly responsible:
zipWithAndUnzipM :: Monad m
= (a - b - m (c, d)) - [a] - [b] - m ([c], [d])
zipWithAndUnzipM f (x:xs) (y:ys)
= do { (c, d) - f x y
; (cs, ds)
schrieb Richard Eisenberg:
Fixed, hopefully!
Mitigated, but still a regression:
http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2base=2%2B68ben=tests%2Falloc%2FT9872aenv=1revs=50equid=on#
Is that now a level that we’ll have to live with, or is it still
unexpectedly high?
Greetings
, 21:51 -0500 schrieb Richard Eisenberg:
Phab has shown up some performance regressions in my recent commits.
See https://phabricator.haskell.org/harbormaster/build/2607/. The
failures except for haddock.base are new, and evidently my fault. They
didn't show up on Travis. Will look
Fixed, hopefully!
On Dec 13, 2014, at 10:03 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
I think I've fixed this. I've pushed the fix to wip/rae, and waiting for
validation results before pushing to master.
My hunch below was right -- it was the change to matchFam, which essentially
On Dec 12, 2014, at 3:30 AM, Adam Gundry a...@well-typed.com wrote:
I did vaguely wonder about doing something like this, but was worried
about the complexity. Since you all seem keen, though, I'll have a go
and see if I can make it work. I'd imagine using the (plugin module
name, axiom
As I'm referenced here, I'll speak up: yes, I think we should advertise that
the plugin interface is purely a technology preview, and very subject to
change. I'm sure that as users adopt this powerful new feature, they and we
will discover ways that it could be improved, or perhaps ways that it
Hi devs,
Phab has shown up some performance regressions in my recent commits. See
https://phabricator.haskell.org/harbormaster/build/2607/. The failures except
for haddock.base are new, and evidently my fault. They didn't show up on
Travis. Will look into it shortly, but I doubt over the
I've been following the plugins stuff at a small distance. I'vm very interested
as a user, but don't have the bandwidth to think deeply as an implementor. With
that caveat, I have a proposal:
Suppose plugin P is responsible for producing CoAxiomRule R while compiling
module M. I think it's
Hi devs,
Previously, I've had much success with the THREADS environment variable for
getting the testsuite to run multiple tests in parallel. This no longer seems
to be working on my Macs. Is this an expected change? Is there something I can
do to fix this locally? It takes a long time to run
Hi devs,
There are various times when we want to make some change to a large number of
lines/files, but the change is very very boring. Two somewhat recent cases that
come to mind are de-tabbing and the .lhs - .hs conversion. These sorts of
changes cause painful merges for anyone who is
Hi devs,
I've just hit on (what I view to be) a design wart in what is allowed in an
instance context inferred through the use of non-standalone `deriving`. I've
posed a problem and potential solution in #8984
(https://ghc.haskell.org/trac/ghc/ticket/8984#comment:6). See Note [Exotic
derived
for 7.10. I'm
agnostic on whether it gets into 7.10, but my tendency is to believe it will
make life easier to merge into 7.10 than not.
Richard
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 02 December 2014 03:15
| To: Simon Peyton
Hi devs,
In unrelated work, I saw this scroll across when happy'ing the parser:
shift/reduce conflicts: 60
reduce/reduce conflicts: 16
These numbers seem quite a bit higher than what I last remember (which is
something like 48 and 1, not 60 and 16). Does anyone know why?
Thanks,
Richard
I'm certainly unaware of any reason this should be expected. I would report as
a bug, and, personally, would label it High priority. I think there is plenty
of room for GHC to be more efficient around type families.
Thanks for putting together a test!
Richard
On Nov 29, 2014, at 5:17 AM, Dr.
I support this direction. But I disagree with one statement you've made:
On Nov 18, 2014, at 11:07 AM, Austin Seipp aus...@well-typed.com wrote:
To be clear: GHC can still typecheck, compile, and efficiently execute
Haskell 2010 code. It is merely the distribution of compatible
packages that
it in roughly a quarter of the time this would take me...
Thanks,
Richard
On Nov 12, 2014, at 5:19 PM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
Am Mittwoch, den 12.11.2014, 13:24 -0500 schrieb Richard Eisenberg:
Hi Joachim,
I just tried to use Travis for validation on my fork
Is it me, or is Trac taking the afternoon off? I haven't been able to access it
for the last two hours or so.
Thanks,
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi devs,
I just stumbled across commit 37d64a5, which (among other things) expands all
the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was
this done? I don't love macros, but I think the old format was easier to look
at and edit.
I know I missed the train a bit on
Hi Joachim,
I just tried to use Travis for validation on my fork of GHC, to avoid sending
out emails associated with a wip/... commit. But, Travis couldn't find the
submodules. Here's the tail of my log:
Submodule 'libraries/vector'
(git://github.com/goldfirere/packages/vector.git)
annoying component of having to deal
with this in the Makefile rules. It could be done, but it's more
annoying.
On Wed, Nov 12, 2014 at 11:27 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:
Hi devs,
I just stumbled across commit 37d64a5, which (among other things) expands
all the LL/L1
I like this idea.
Would it be a good idea to add a new difficulty classification for bugs that
could flag them as newcomer-appropriate? I don't think Easy is this
classification, because there are many bugs that are easy if you know exactly
where to look but nigh impossible otherwise. If it
Forgive me if I'm repeating others' comments, but the newcomer label, to me, is
independent of level of difficulty -- it has much more to do with how messy
the work is, I think.
I'll make a concrete proposal: Tag appropriate bugs/feature requests with
newcomer and, if you want, mention that
Let me restate the proposals more concretely. Correct me if I'm wrong!
Suppose we have the following declarations:
data T a b where
MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b
pattern P x y = MkT 5 (y, True) x
What is the type of P?
Simon's proposal:
pattern P :: (Eq a,
On Nov 10, 2014, at 3:33 AM, Joachim Breitner m...@joachim-breitner.de wrote:
We could experimenting with just sending those „branch wip/foo's head
updated“ mails, i.e. only one mail per push, listing the git commit
titles. That would greatly reduce the traffic, while still giving some
Hi Iavor,
Great!
For the workflow question: See
https://ghc.haskell.org/trac/ghc/wiki/Phabricator, which contains all the
details. The short version for your needs: install `arc` (see the wiki page)
and then say `arc diff` on your branch. Note that `arc diff` will change your
commit message.
While I'll admit I still like my bikeshed color choice over Simon's, I'm happy
to go with the fact that there seems to be more momentum behind Simon's.
Instead, let me propose a slight change of shade: put the required
constraints *first* and the provided ones *second*. Of course, we could
On Nov 9, 2014, at 2:42 PM, Joachim Breitner m...@joachim-breitner.de wrote:
Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
I've stopped validating locally, allowing Travis to do it for me. If
you use a `wip/...` branch and push to the main GHC repo, you can find
build
On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones simo...@microsoft.com wrote:
* One other possibility would be two = thus
pattern P :: (Eq b) = (Num a, Eq a) = ...blha...
I should note that I can say this in 7.8.3:
foo :: Show a = Eq a = a - String
foo x = show x ++ show (x == x)
On Nov 8, 2014, at 11:23 AM, Dr. ERDI Gergo ge...@erdi.hu wrote:
So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um)
into a type, which would then require rejecting everywhere else where we
really do mean a type... Sounds painful. Also painful: rewriting the whole
I've stopped validating locally, allowing Travis to do it for me. If you use a
`wip/...` branch and push to the main GHC repo, you can find build reports at
travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work
if you push to your own GitHub fork of GHC.
Admittedly,
On Nov 8, 2014, at 10:42 PM, Dr. ERDI Gergo ge...@erdi.hu wrote:
Right, but the issue in this case is if we add this artifical constructor to
HsType just so we can fix it up into a pair of contexts, this constructor
would permeate everything else that has to do with HsTypes; if nothing
Is it possible to get the full build logs on Phab? I just had a testsuite
(framework) failure, but I can't see what test caused it!
(https://phabricator.haskell.org/harbormaster/build/1686/)
Thanks,
Richard
On Nov 4, 2014, at 10:38 AM, Simon Peyton Jones simo...@microsoft.com wrote:
I built
How about
pattern type forall a. Num a = P :: forall c. (Eq a, Ord Bool, Show c) = c
- Bool - T a Bool
or
pattern type forall a. Num a = P - forall c. (Eq a, Ord Bool, Show c) = c
- Bool - T a Bool
for a unidirectional pattern. (Note that `::` became `-`.)
This resembles the syntax for
Try `make clean` in the libraries directory and then building again. I usually
need to run `make` twice in a row to build after cleaning the libraries.
On Nov 3, 2014, at 11:48 AM, Simon Peyton Jones simo...@microsoft.com wrote:
Usually this is to do with stale .hi files
From: ghc-devs
I've done a validate on my Mac. Here is the output (indented), with comments
(outdented):
../../libraries/base/tests/IO hReady002 [bad stderr] (normal)
Succeeded on a later run
cabal/cabal01 cabal01 [bad exit code] (normal)
Wrong exit code (expected 0 , actual 2 )
Hi devs,
There's a feature I've wanted for some time, and I don't see a good reason not
to ask: Is it possible to email comments into Trac? My commute involves a ~40
minute train ride, which I generally can use productively despite no
connection. One of the biggest annoyances, though, is that
I just revised a Phab revision using `arc`, and it all worked swimmingly, doing
exactly what I wanted, even though this was non-trivial. I describe the process
below, and am happy to add to the Phab wiki page, but wanted to check here
first to make sure I wasn't making an invisible dreadful
---
commit e319d6d2704edc2696f47409f85f4d4ce58a6cc4
Author: Richard Eisenberg e...@cis.upenn.edu
Date: Mon Oct 20 15:36:57 2014 -0400
Reify data family instances correctly.
Summary:
Fix #9692.
The reifier didn't account for the possibility that data/newtype
instances
Hi Sophie,
I agree with Simon in that I'm skeptical that arrows should *require* a change
in Core, but I'm more willing to believe that a change in Core could permit
better optimizations over arrow-intensive code. Though, I would say we should
spend some time looking for ways to achieve this
Hi all,
Is there a way to put `arc` into a read-only mode?
Frequently while working on a patch, I make several commits, preferring to
separate out testing commits from productive work commits and non-productive
(whitespace, comments) commits. Sometimes each of these categories are
themselves
I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these
are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add
`default` method type signature support), both of which introduce new
constructors for `Dec`. This got me thinking about `Dec` and the fact
On Oct 17, 2014, at 12:32 PM, Austin Seipp aus...@well-typed.com wrote:
Here's how I would imagine what it would look like: Below the
'Summary' field, there is the 'Test Plan' field (as in D344). We can
add another field, 'Patch Roadmap', that appears the same way (i.e. a
bulk textedit
Hi devs,
I have what I hope is a simple request: that patch submissions contain a road
map describing the patch. I'll illustrate via example: I just took a quick
look at D323, about updating the design of Uniques. Although this patch was
fairly straightforward, I would have been helped by a
In direct answer to your question, there's not a great way to step through the
code. As far as I know, there isn't a way to load GHC into GHCi. Personally, I
think a lot about the type-checker and so use -ddump-tc-trace a lot. You can
line up the output with the code to see what is going on.
I think the arc barrier is significant. Personally, while I feel quite
comfortable hacking on Haskell code, system tools are always a bit of a
mystery. Those of you who help manage the infrastructure may feel like the
tools are easy enough to pick up, but I'm sure there are many competent
I've just finished reading this:
http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
For better or worse, I don't read reddit often enough to hold a conversation
there, so I'll ask my question here: Is there a way we can turn GitHub pull
requests
A modest counter-proposal to this idea:
What if we just stopped requiring commas in import/export lists? As far as I
can tell, they're not necessary for proper parsing.
This doesn't solve other problems, but I'm not convinced every problem in this
domain needs the same solution.
In
On Sep 15, 2014, at 9:22 AM, Austin Seipp aus...@well-typed.com wrote:
On Wed, Sep 10, 2014 at 6:32 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
1. Would it be possible to add a new custom field to Trac called Wiki
page? Tickets that are
about implementing a larger feature have an
Hi Merijn,
I believe that `If` is already the way you want:
λ :k If
If :: Bool - k - k - k
The problem in your code is that GHC is a little... er... unprincipled about
the kind of `()`. It basically assumes that `()` is of kind `*` unless it is
very, absolutely, abundantly obvious that it
For what it's worth, my thought is not to use SrcSpanInfo (which, to me, is the
wrong way to slice the abstraction) but instead to add SrcSpan fields to the
relevant nodes. For example:
| HsDoSrcSpan -- of the word do
BlockSrcSpans
Hi Gergo,
There is indeed something strange about that output. The good news is that I'm
not convinced you need `unifyType`, but I'm not sure exactly what you do need.
- There is nothing, in general, inside the `cobox`es. Those are just variables.
In the Core you include, they're out of scope,
Simon,
I've been encouraging the type family approach. See
https://phabricator.haskell.org/D157
Thanks,
Richard
On Aug 15, 2014, at 11:17 AM, Simon Peyton Jones simo...@microsoft.com wrote:
Eek. Glancing at this I see that every single data type has an extra type
parameter. To me this
Hi all,
I wanted to see a side-by-side diff of the GHC code between 7.8.2 and 7.8.3.
So, I went to Phab's Diffusion application. I can access the different commits
I wish to compare, but I can't seem to find a Compare or Diff button.
Any hints?
Thanks!
Richard
Hi all,
I've prepared a bunch of commits to fix several tickets. After pushing these
commits to branch wip/rae (to save my place and to get validate running on
Travis), I then `git checkout`ed back to a point where `git diff origin/master`
gave me a patch for precisely one bug (instead of the
What if there is a good reason for a missing/broken Data.Data instance? I'm
specifically thinking of GADTs. There are few currently, but I, for one, have
toyed with the idea of adding more. My recollection is that Data.Data doesn't
work with GADTs. As a concrete, existent example, see
doesn't hold.
Simon
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 22 July 2014 13:22
| To: Simon Peyton Jones
| Cc: ghc-devs@haskell.org
| Subject: Re: tcInferRho
|
| OK -- that all makes sense.
|
| But why does it actually work, I wonder
On Jul 22, 2014, at 9:58 AM, Austin Seipp aus...@well-typed.com wrote:
Hi Richard,
Sorry for missing this email - it slid out of my queue...
No worries on the delay. I wouldn't be surprised if there is a Best Practices
document somewhere which advises waiting at least several days to
Oops. I was relying on Travis's validation, which skips haddocking.
This is most likely why Phab's build failed.
Thanks for fixing it!
Richard
On Jul 17, 2014, at 4:44 AM, Simon Hengel s...@typeful.net wrote:
On Thu, Jul 17, 2014 at 08:21:43AM +, Simon Peyton Jones wrote:
| parse
Hi all,
I'm trying to use Phab for the first time this morning, and hitting a fair
number of obstacles. I'm writing up my experiences here in order to figure out
which of these are my fault, which can be fixed, and which are just things to
live with; and also to help others who may go down the
Hi all,
I wanted to make a comment in a Phab revision and refer to performance of a
particular commit. So, I found the Local commits section of my page
(https://phabricator.haskell.org/D73). But, those SHA's (Commit and Tree)
seem not to be related to others. The correct SHA, as I can see it,
I've discovered that passing options to `make` doesn't necessarily work all
that well. Certain ones work great, but it's not as reliable as I might like.
That said, have you tried running the command in the ./ghc subdirectory? (Not
the top directory -- it's probably ./ghc/ghc on your
I'd like to humbly second this request... and specifically, that I more often
use git in fear rather than confidence, especially when I'm working with ghc.
This is perhaps inevitable -- a complicated system requires complicated tools.
But, any help here is greatly appreciated.
As a very minor
Hi all,
I'm deep into working on #9233 right now, which may stem from various
inefficiencies due to roles. I'm making good progress, and I feel badly about
introducing these problems. When I was coding this originally, I was thinking
Premature optimization is the root of all evil and didn't
Hi all,
Sometimes, the progress on a particular issue is tracked both on Trac and on
Phab. What posts should go where? I know Austin is trying to get Trac to be
notified when a relevant post happens on Phab -- great. But, if I have a
comment, where should I put it?
Here is my proposed answer:
Hello Alan,
It's not clear what you're asking for here. What's keeping you from accessing
the full power of the GHC type system?
Richard
On Jul 9, 2014, at 4:35 PM, AlanKim Zimmerman alan.z...@gmail.com wrote:
I have hit a problem in HaRe when lifting a declaration from e.g. a where
clause
the entire compilation.
Alan
On Sun, Jul 13, 2014 at 10:21 PM, Richard Eisenberg e...@cis.upenn.edu
wrote:
Hello Alan,
It's not clear what you're asking for here. What's keeping you from
accessing the full power of the GHC type system?
Richard
On Jul 9, 2014, at 4:35 PM, AlanKim
I'm not convinced I have very good taste where it comes to concrete syntax, but
I will say that the `injective` keyword below is redundant -- it can be
inferred from the presence of the `|`.
Also, by restriction (b), I imagine you also allow things like `Maybe a`, where
`a` is a variable bound
I have mixed feelings on all of this.
First, a disclaimer: I have a significant (~10,000 lines of difference,
perhaps) branch and would be hit hard by this change. (Branch is at
github.com/goldfirere/ghc under the nokinds branch.) That said, if I'm
careful as I'm merging, I could probably make
Thanks, Johan, for starting this discussion.
I mostly agree with the proposal. However, one (at times, serious) drawback to
using Haddock is that it means that editing comments can cause parse failures.
The way the GHC build works, these failures may not be detected until the end
of a hacking
I'm sure I've used the feature that you're proposing to remove, but I'll adapt.
To be clear, the change means no loss of expressiveness, just that I'll
sometimes have to use a helper type family (closed or open), right?
If I'm right there, then no complaints from me.
Richard
On Jun 24, 2014,
601 - 700 of 819 matches
Mail list logo
