Hi,
If I build the code below with -DVER=2, I get a complaint about
PatchInspect (PrimOf p) being missing from the context of
cleverNamedResolve.
This doesn't happen with -DVER=1 or -DVER=3
I presume that type class resolution is operating slightly differently
in the different cases, but it's
Simon Marlow wrote:
Hopefully that explains why sometimes we make breaking changes. If
the
breaking change has a high enough impact, then it becomes worthwhile
to
add backwards compatibility (via warnings / deprecation or whatever).
Of course from the point of view of the user, the
Mitar wrote:
Hi!
On Thu, Sep 23, 2010 at 2:19 PM, Christian Maeder
christian.mae...@dfki.de wrote:
I tend to introduce artificial error cases for the Impossible, to
avoid warnings, although the compiler generated error messages are
better to locate the problem.
But this is often
Hi,
I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40
signatures for MonoLocalBinds in about 140 files/30K LOC. Is that about
normal? darcs does make fairly heavy use of rank 2 polymorphism which
leads to quite a lot of local definitions needing to be polymorphic.
Also,
Simon Marlow wrote:
On 02/11/2010 07:37, Sittampalam, Ganesh wrote:
I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40
signatures for MonoLocalBinds in about 140 files/30K LOC. Is that
about normal? darcs does make fairly heavy use of rank 2 polymorphism
which leads to quite
Sebastian Fischer wrote:
Dear GHC experts,
Certain behaviour when using
{-# LANGUAGE GADTs, TypeFamilies #-}
surprises me. The following is accepted by GHC 6.12.1:
data GADT a where
BoolGADT :: GADT Bool
foo :: GADT a - a - Int
foo BoolGADT True = 42
Sebastian Fischer wrote:
With GADTs, the specific choice of constructor is what gives you the
type matching functionality.
My intention was to use a GADT as data family instance (hence, I
wrote it in GADT style and it was accepted as such). Can't GADTs be
used as data family instances?
Try darcs optimize --reorder in your repo, or pull your patch into a freshly
got repo. (Annoying internal detail of darcs - it probably won't use the tag
unless it's clean, which requires that any patches not included in the tag
should be after it in the repo order)
-Original Message-
Dave Bayer wrote:
There's clearly something wrong with this picture. A Rorschach blot
test as to what's wrong, but I see people overreaching, if I have to
wait weeks for a simple install tool, then months for the Haskell
Platform to be ready.
Hopefully future GHC releases will go more
Simon Marlow wrote:
This is a game for the whole family! We don't care how much progress
you make on each ticket, just as long as someone has taken a look and
moved the ticket forward in some way. For example, you might check
for duplicates, update the metadata, ask for more information
Ross Paterson wrote:
On Mon, Nov 02, 2009 at 02:05:01PM +, Simon Marlow wrote:
You need array 0.3.0.0 which comes with GHC 6.12rc1, but is
(probably) not on Hackage yet.
No it isn't: array-0.3.0.0 will be defined by what's released in GHC
6.12.
That creates a timing problem, given that
Ian Lynagh wrote:
You already have the array 0.3.0.0 package if you installed the RC.
The problem is that the darcs.cabal file says: build-depends:
[...] array = 0.1 0.3,
[...]
so it's not using it.
Oh, I see. Sorry for the noise - I got
Simon Peyton-Jones wrote:
Fortunately, I don't think a lot of people use the feature in anger.
Please yell if you *are* using impredicative polymorphism for
something serious. But if you are, we need to think of a workaround.
The current situation seems unsustainable.
I think darcs is
Simon Marlow wrote:
The current dilemma we're facing with the 6.12.1 release is this:
cabal-install still needs to be ported to the new version of Cabal,
Duncan is snowed under and doesn't have time to work on it, but
without cabal-install people can't easily test 6.12.1 RC and we can't
test
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we have
some automation to check that changes are indeed getting pushed
upstream.
Agreed. Can you think of an easy way to automate it?
How about a cronjob that runs
darcs send upstream-repo --to=some-list
Simon Marlow wrote:
On 27/08/2009 11:18, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we
have some automation to check that changes are indeed getting
pushed upstream.
Agreed. Can you think of an easy way to automate
Simon Marlow wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we
have some automation to check that changes are indeed getting
pushed upstream.
[snip unhelpful suggestion from me]
Yes, it tells you that you've screwed up, rather than telling you
Niklas Broberg wrote:
I believe, Language.Haskell.Pretty can properly output haskell code
(and the GHC API should be able to do so, too. Does the GHC API
output tabs?)
Surely you mean Language.Haskell.Exts.Pretty, right? ;-)
The haskell-src-exts library does not (yet) support full
Simon Marlow wrote:
On 20/06/2009 21:46, Ganesh Sittampalam wrote:
If I'm right, is it really sensible for every handle to have this
finalizer? Closing a pipe has externally visible side effects beyond
just the release of resources, so it doesn't seem like it should
happen
Duncan Coutts wrote:
Niklas's and my point is
that the list of language extensions in Language.Haskell.Exceptions
are differences from H98 so it should be MonoPatBinds to get the
difference not NoMonoPatBinds to restore H98.
In practise, since ghc uses MonoPatBinds by default it'd
Peter Gammie wrote:
On 13/05/2009, at 6:43 PM, Bayley, Alistair wrote:
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of
Peter Gammie
The semantics I want is:
- use the Cabal-built objects/hi files in dist/build if they're
John Meacham wrote:
On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote:
So I accept that we do not yet cover the range of configuration
choices that are needed by the more complex packages (cf darcs), but
I
think that we can and that the approach is basically sound. The fact
Brandon S Allbery wrote:
On 2008 Aug 10, at 20:17, Norman Ramsey wrote:
For the last year I have been hoping to make 'a new darcs-like
thing,
with a real theory founding it' an important part (one of three) of
a
grant proposal in distributed computing. So you can see I am in
favor
of
Thomas Schilling wrote:
(I am also no longer convinced that Darcs'
automatic patch dependency calculations are
actually a good idea. Just because two patches
don't touch the same files, doesn't mean they
aren't semantically dependent. Take for
example monadification patches, which are
-Original Message-
From: Thomas Schilling [mailto:[EMAIL PROTECTED]
Sent: 11 August 2008 12:18
To: Sittampalam, Ganesh
Cc: Manuel Chakravarty; Don Stewart; Ian Lynagh; Simon Peyton-Jones; GHC
Users Mailing List
Subject: Re: Version control systems
Thomas Schilling wrote:
On 11 Aug
Hi,
module A(A) where
data A
deriving Show
I think you should use instance Show A rather than deriving Show.
All the boot file needs to do is say that the instance exists, not
explain how it is constructed.
Cheers,
Ganesh
Simon Peyton Jones wrote:
| It worked, with:
|
| {-# INLINE [1] begin1 #-}
| {-# INLINE begin2 #-}
|
| I don't think this approach will compose particularly well, and in
the
| real case I was trying (not this reduced example) I don't think it
| will work because there is some recursion
Well, Ord Foo doesn't hold, does it? So Ord (a, b) isn't equivalent to (Ord a,
Ord b).
Ganesh
-Original Message-
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]
Sent: 27 March 2008 09:05
To: Sittampalam, Ganesh; 'Tom Schrijvers'; Ganesh Sittampalam
Cc: glasgow-haskell-users
If you write the instance
instance Theta = Foo (T a b) where ...
where Theta is an arbitrary context, then, given a dictionary for (Foo (T a
b)), you can get dictionaries for each constraint in Theta. Or in logic
Theta = Foo (T a b)
In your example, Theta is empty.
If
Tom Schrijvers wrote:
On Wed, 26 Mar 2008, Ganesh Sittampalam wrote:
On Wed, 26 Mar 2008, Ross Paterson wrote:
On Wed, Mar 26, 2008 at 08:52:43PM +, Ganesh Sittampalam wrote:
I'm a bit confused about why the following program doesn't compile
(in any of 6.6.1, 6.8.1 and 6.9.20080316).
Because I want to be able to make Foo values where the parameter type isn't in
Ord, too. I just want unFoo to work on specific Foo values where it is.
-Original Message-
From: Claus Reinke [mailto:[EMAIL PROTECTED]
Sent: 27 March 2008 12:25
To: Sittampalam, Ganesh; Ganesh Sittampalam
Cc
Because I want to be able to make Foo values where the parameter type
isn't in Ord, too. I just want unFoo to work on specific Foo values where
it is.
but your recursive function requires a recursive constraint, which your data
type does not guarantee byconstruction, and which the
Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't
apply with -traditional?)
I think it bit me last week. I had something like:
It bites me too - something like this goes wrong with ghc -cpp:
#define C(x) x
foo' :: foo C(x)
Ganesh
I think that if you use the HEAD, much of
this will work, if you use the type-equality
notation. But you will probably encounter bugs
too. And in so doing, and reporting them, you'll
be doing us a service.
I did originally intend to try all this with the
HEAD, but one obstacle to this is
What about integrating a complete list into ghc which can accessed by
ghc --full-flag-help | less ?
Sure I can fake it and get that list out of the html documentation. I
just want to know if someone else would like this flag, too
I would find it very useful too.
Ganesh
Hi,
I've installed Visual Haskell and am having some trouble with the Intellisense
functionality. It works fine on a small project I start from scratch, but
doesn't work at all for a bigger project (no tooltips, Go to Definition
doesn't work, etc etc). Is there any way to debug this?
Cheers,
Sorry, I forgot to make clear that the project builds fine from inside the IDE.
-Original Message-
From: Pepe Iborra [mailto:[EMAIL PROTECTED]
Sent: 15 January 2007 16:06
To: Sittampalam, Ganesh
Cc: 'GHC users'
Subject: Re: No intellisense in Visual Haskell
Ganesh,
In my experience
-is in
the GHC options, but I'd be inclined to view this as a bug, as I think this is
a fairly standard way of working with modules - what do you think?
Cheers,
Ganesh
-Original Message-
From: Krasimir Angelov [mailto:[EMAIL PROTECTED]
Sent: 15 January 2007 16:48
To: Sittampalam, Ganesh
Cc: Pepe
38 matches
Mail list logo
