exhausted simplifier ticks and hs-boot files
Hi,
The code below (also attached - unzip and run go.sh) triggers the GHC
panic "Simplifier ticks exhausted", and I'm unsure whether I should view
it as an instance of the known infelicity in the inliner
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#bugs-ghc)
My code does have a recursive datatype, but the recursion isn't
contravariant, which is the case described in "Secrets of the GHC
inliner"
(https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf,
section 4).
It's cut down from some real code where I have a mutually recursive
datatype that I want to define across two modules for code structuring
reasons, meaning I need a .hs-boot file. I haven't been able to
reproduce it without the .hs-boot file - if I put everything in one
module it stops happening.
I've tried with a range of GHC versions from 8.2.x to an early version
of 8.8. It happens with -O1 and not -O0, but I haven't managed to find a
specific optimisation that triggers it.
Is this just an instance of the known problem in a different guise, or
is it something different and worth a bug report?
Cheers,
Ganesh
T2.hs-boot
---
module T2 where
data T2
mapP_T2 :: (Int -> Int) -> T2 -> T2
T1.hs
-
module T1 where
import {-# SOURCE #-} T2
data T1 = T1 T2
mapP_T1 :: (Int -> Int) -> T1 -> T1
mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
T2.hs
-
module T2 where
import T1
data T2 = T2 T1
mapP_T2 :: (Int -> Int) -> T2 -> T2
mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
go :: T1 -> T1
go = mapP_T1 id
GHC output
--
$ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats)
[...]
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone mapP_T2
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
Total ticks: 61203
24481 PreInlineUnconditionally
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
12241 UnfoldingDone
6121 mapP_T1
6120 mapP_T2
24481 BetaReduction
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
<>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [core libraries] Re: Tightening up on inferred type signatures
On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote: Edward Kmett ekm...@gmail.com writes: You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Good point. In particular, it's not weird at all want to export type synonyms on their own, particularly where ghost type parameters are used to select between only a few cases. Consider something like this (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: PROPOSAL: Literate haskell and module file names
The behaviour could be invoked only for lower-case parts, but that may prove problematic on case-insensitive filesystems like Windows. On 16/03/2014 13:52, Carter Schonwald wrote: Idk, this behavior of doing Data.Vector.lhs seems pretty awesome. I actually might start doing that. That ghc allows that seems pretty darn awesome. And handy too On Sunday, March 16, 2014, Merijn Verstraaten mer...@inconsistent.nl mailto:mer...@inconsistent.nl wrote: My personal approach would have been to make ghc accept Foo.*.lhs, maintaining a list of potential file format seems arduous and error prone. Cheers, Merijn On Mar 16, 2014, at 14:13 , Joachim Breitner wrote: Hi, Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: Cons: GHC would have to either maintain a possibly long of variants to look for ([.hs, .lhs, .rst.lhs, .md.lhs, .svg.lhs, .docx.lhs]), or look for Foo.*.lhs. I’d find the latter acceptable, but it should be noted. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de javascript:; • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de javascript:; • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org javascript:; ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Just to note a problem I encountered on Windows, which may well be user error. I unpacked the mingw tarball and added the bin directory from it to my path. cabal install then failed with cabal.exe: does not exist after producing some other output. Running with -v3 suggested that the actual problem was that the ld on my path couldn't read the .o files produced by GHC. I changed my path to also include the mingw\bin directory from the tarball, and then all was fine. On 03/02/2014 22:35, Austin Seipp wrote: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
I feel this blurs the roles of GHC and the Platform. Can't the cabal-install that comes with the Platform can be used with a later GHC installation? If that's correct, then the only use case that this proposal covers is someone who wants to use a bleeding edge GHC and no other version on a new machine. A separate binary distribution of cabal-install should be more than adequate for that and it avoids coupling GHC to other things. So a weak -1. On 20/01/2014 00:02, Carter Schonwald wrote: Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
If you can't find any better options, I can try to run a buildbot on a laptop that's probably mostly online. On 21/01/2014 19:32, Johan Tibell wrote: We could offer OS X and Linux binaries in addition to the Windows binaries already downloaded on the cabal home page (http://www.haskell.org/cabal/) if someone could commit to building them. Aside: Right now building the Windows binaries is a very ad-hoc process (I email Mikhail who has a Windows machine and ask him to build one). I'm not very keen to make the process even slower, given that that will mean I will make fewer cabal releases. Ideally the binaries could be produced on a build bot. The very least we should have the Makefile in the cabal repo being able to create the binary in a reproducible manner. -- Johan On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam gan...@earth.li mailto:gan...@earth.li wrote: I feel this blurs the roles of GHC and the Platform. Can't the cabal-install that comes with the Platform can be used with a later GHC installation? If that's correct, then the only use case that this proposal covers is someone who wants to use a bleeding edge GHC and no other version on a new machine. A separate binary distribution of cabal-install should be more than adequate for that and it avoids coupling GHC to other things. So a weak -1. On 20/01/2014 00:02, Carter Schonwald wrote: Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter ___ Libraries mailing list librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default roles
I think it would be ok to expect the constructors to be visible, even
though it might need to a lot being needed.
BTW I think you might need S1 visible as well otherwise how would you
convert (S1 True :: S Bool Int) into (S1 True :: S Bool Age)?
If you don't derive the role from constructor visibility then I think it
should fail-safe and default to the nominal role - valid Haskell 2010
code shouldn't be exposed to an abstraction leak just because it's GHC
compiling it.
On 08/10/2013 14:23, Richard Eisenberg wrote:
Pedro is suggesting a way for a Haskell type-level program to gain
access to role information. This might indeed be useful, but it
doesn't seem terribly related to the problem of defaults /
abstraction. The problem has to do with definitions like these:
module A where
data S a b = S1 a | S2 b
data T a b = MkT (S a b)
module B where
import A ( {- what goes here? -} )
class C a where
mkT :: T Bool a
instance C Int where ...
newtype Age = MkAge Int deriving C
What constructors do we need in order to convert the (C Int) instance
to (C Age) by hand? To me, it looks like we need MkT and S2, but not
S1. Yet, this is not obvious and seems to be quite confusing.
I hope this helps understanding the issue!
Richard
On Oct 8, 2013, at 4:01 AM, José Pedro Magalhães drei...@gmail.com
mailto:drei...@gmail.com wrote:
Hi,
On Tue, Oct 8, 2013 at 3:21 AM, Richard Eisenberg e...@cis.upenn.edu
mailto:e...@cis.upenn.edu wrote:
We considered this for a while, but it led to a strange design --
to do it right, you would have to import all constructors for all
datatypes *recursively* out to the leaves, starting at the
datatypes mentioned in the class for which you wanted to use GND.
This would mean potentially a whole lot of imports for symbols
not actually used in the text of a program.
I'm not sure I understand why constructors are involved in this.
Wouldn't something like
the following potentially be useful?
data Role = Nominal | Representational | Phantom | Fun Role Role
type family HasRole (t :: k) :: Role
data MyData a b = MyData a
data MyGADT a b where MyGADT :: MyGADT a Int
type instance HasRole MyData = Fun Representational Phantom
type instance HasRole MyGADT = Fun Representational Nominal
type instance HasRole Traversable = Nominal
HasRole instances would be automatically given by GHC.
Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default roles
Is it possible to tie the role to whether the data constructor is
visible or not?
On 07/10/2013 14:26, Richard Eisenberg wrote:
As you may have heard, /roles/ will be introduced with GHC 7.8. Roles
are a mechanism to allow for safe 0-cost conversions between newtypes
and their base types. GeneralizedNewtypeDeriving (GND) already did this
for class instances, but in an unsafe way -- the feature has essentially
been retrofitted to work with roles. This means that some uses of GND
that appear to be unsafe will no longer work. See the wiki page [1] or
slides from a recent presentation [2] for more info.
[1] : http://ghc.haskell.org/trac/ghc/wiki/Roles
[2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf
I am writing because it's unclear what the *default* role should be --
that is, should GND be allowed by default? Examples follow, but the
critical issue is this:
* If we allow GND by default anywhere it is type-safe, datatypes (even
those that don't export constructors) will not be abstract by default.
Library writers would have to use a role annotation everywhere they wish
to declare a datatype they do not want users to be able to inspect.
(Roles still keep type-*un*safe GND from happening.)
* If we disallow GND by default, then perhaps lots of current uses of
GND will break. Library writers will have to explicitly declare when
they wish to permit GND involving a datatype.
Which do we think is better?
Examples: The chief example demonstrating the problem is (a hypothetical
implementation of) Set:
module Set (Set) where -- note: no constructors exported!
data Set a = MkSet [a]
insert :: Ord a = a - Set a - Set a
...
{-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
module Client where
import Set
newtype Age = MkAge Int deriving Eq
instance Ord Age where
(MkAge a) `compare` (MkAge b) = b `compare` a -- flip operands,
reversing the order
class HasSet a where
getSet :: Set a
instance HasSet Int where
getSet = insert 2 (insert 5 empty)
deriving instance HasSet Age
good :: Set Int
good = getSet
bad :: Set Age
bad = getSet
According to the way GND works, `good` and `bad` will have the same
runtime representation. But, using Set operations on `bad` would indeed
be bad -- because the Ord instance for Age is different than that for
Int, Set operations will fail unexpectedly on `bad`. The problem is that
Set should really be abstract, but we've been able to break this
abstraction with GND. Note that there is no type error in these
operations, just wrong behavior.
So, if we default to *no* GND, then the deriving line above would have
an error and this problem wouldn't happen. If we default to *allowing*
GND, then the writer of Set would have to include
type role Set nominal
in the definition of the Set module to prevent the use of GND. (Why that
peculiar annotation? See the linked further reading, above.)
Although it doesn't figure in this example, a library writer who wishes
to allow GND in the default-no scenario would need a similar annotation
type role Foo representational
to allow it.
There are clearly reasons for and against either decision, but which is
better? Let the users decide!
Discussion time: 2 weeks.
Thanks!
Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
implicit params in instance contexts
Hi,
It seems that from GHC 7.4, the prohibition on implicit parameter
constraints in instance declarations has been relaxed. The program below
gives the error Illegal constraint ?fooRev::Bool in GHC 7.2.1 but
loads fine in GHC 7.4.2 and GHC 7.6.2.
I can't spot anything about this in the release notes, and the
documentation
(http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extensions.html#idp49069584)
still says You can't have an implicit parameter in the context of a
class or instance declaration.
So I wonder if this happened by accident, perhaps as part of the
ConstraintKinds work or similar?
I've wanted this feature a few times so if it's going to stay I might
start using it. However it is a bit dangerous, so if it was added by
accident it might warrant some discussion before deciding to keep it.
For example as the value set2 below shows, it can be used to violate
datatype invariants.
Cheers,
Ganesh
{-# LANGUAGE ImplicitParams #-}
module Ord where
import Data.Set ( Set )
import qualified Data.Set as Set
newtype Foo = Foo Int
deriving (Eq, Show)
instance (?fooRev :: Bool) = Ord Foo where
Foo a `compare` Foo b =
if ?fooRev then b `compare` a else a `compare` b
set1 = let ?fooRev = False in Set.fromList [Foo 1, Foo 3]
set2 = let ?fooRev = True in Set.insert (Foo 2) set1
-- Ord set2
-- fromList [Foo 2,Foo 1,Foo 3]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 10/02/2013 21:43, Ian Lynagh wrote: On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. As the maintainer of a low-level package (HTTP), I certainly see this kind of pressure starting even before a GHC release - e.g. https://github.com/haskell/HTTP/issues/36 As one of the maintainers of a high-level tool (darcs) that aims to always build against the current HP, I generate this kind of pressure myself: once GHC is released, I expect it to be in the HP within 3-6 months, so I need to get started quickly. I can't even check darcs itself until the dependencies work. I don't think there are any easy answers :-/ Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 28/11/2012 13:13, Ian Lynagh wrote: My general feeling about Windows is that it's ok for the end result to be a little annoying, because Windows DLLs *are* annoying and it's nothing to do with GHC. In particular I think in practice most Windows developers will have admin rights and could live with the ghc installation and cabal install having to be done as elevated operations. Where they weren't done with admin rights, then ghc -o could warn the user that the DLLs need to be copied locally (or even copy them itself and tell the user it happened). Personally, I would prefer the C stub option to that. I think that one would be ok too, but I somewhat prefer SxS simply because of the long-term costs of being non-standard. More generally, if you can implement the half a plan you mentioned elsewhere in the thread for quickly building both static and dynamic ways, then the combination of the ABI and performance issues mean that I'm marginally in favour of keeping static linking as the default for executables on all platforms, but building the dynamic libraries for ghci. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Can't ghc -c also produce both static and dynamic objects? I guess only one of the two could be called sourcefile.o Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing binary tarball fails on Linux
On 01/10/2012 12:05, Simon Marlow wrote: This probably means that you have packages installed in your ~/.cabal from a 32-bit GHC and you're using a 64-bit one, or vice-versa. To avoid this problem you can configure cabal to put built packages into a directory containing the platform name. How does one do this? I ran into this problem a while ago and couldn't figure it out: http://stackoverflow.com/questions/12393750/how-can-i-configure-cabal-to-use-different-folders-for-32-bit-and-64-bit-package Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.6.1 RC1 panic coVarsOfTcCo:Bind
Hi Simon,
Now I get the below.
I tarred up the project + dependencies and put it at
http://urchin.earth.li/~ganesh/temp/tcproblem.tar.bz (run build.sh), or
I'm happy to keep testing on my machine.
Cheers,
Ganesh
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.6.0.20120822 for i386-unknown-mingw32):
ds_ev_term
cobox{v a6Aho} [lid] `cast`
(main:Darcs.Test.Patch.WithState.WithState{tc r1oms}
model{tv t4H} [tv]
(main:Darcs.Witnesses.Ordered.FL{tc
r1iNn} prim{tv t4D} [tv]
main:Darcs.Witnesses.Ordered.:{tc
r1iNy} main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv])
ghc-prim:GHC.Types.~{(w) tc 31Q}
main:Darcs.Test.Patch.WithState.WithState{tc r1oms}
(Sym
cobox{v a6AgE} [lid])
main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1iNy}
main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv])
(let {EvBinds{cobox{v a6zY5} [lid]
= cobox{v a6Aho} [lid] `cast`
(main:Darcs.Test.Patch.WithState.WithState{tc r1oms}
model{tv t4H} [tv]
(main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1iNy}
main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv])
ghc-prim:GHC.Types.~{(w) tc 31Q}
main:Darcs.Test.Patch.WithState.WithState{tc r1oms}
(Sym
cobox{v a6AgE} [lid])
main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1iNy}
main:Darcs.Witnesses.Ordered.FL{tc r1iNn}
prim{tv t4D} [tv])
cobox{v a6zY6} [lid] = CO t{tv a6zY1} [tv]}}
cobox{v a6zY5} [lid] xx{tv a6zY3} [sk] yy{tv a6zY4} [sk]
- t{tv a6zY1} [tv])
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
On 22/08/2012 08:40, Simon Peyton-Jones wrote:
Ah. Hmm. I see.
Can you try this in TcEvidence
-- We expect only coercion bindings
go_bind :: EvBind - VarSet
go_bind (EvBind _ (EvCoercion co)) = go co
go_bind (EvBind _ (EvId v))= unitVarSet v
go_bind other = pprPanic coVarsOfTcCo:Bind (ppr other)
with this instead?
-- We expect only coercion bindings, so use evTermCoercion
go_bind :: EvBind - VarSet
go_bind (EvBind _ tm) = go (evTermCoercion tm)
I think that'll fix it.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-
| haskell-users-boun...@haskell.org] On Behalf Of Ganesh Sittampalam
| Sent: 22 August 2012 06:32
| To: glasgow-haskell-users@haskell.org
| Subject: 7.6.1 RC1 panic coVarsOfTcCo:Bind
|
| Hi,
|
| I'm getting the panic below when building darcs 2.8 with GHC 7.6. It'll
| take some effort to cut it down or give repro instructions for an
| uncut-down version (I needed to hack a lot of underlying packages to be
| able to even get as far as doing this build), so could someone confirm
| that it's worth it before I do so? I can't spot anything already
| reporting this in trac.
|
| Cheers,
|
| Ganesh
|
| ghc.exe: panic! (the 'impossible' happened)
| (GHC version 7.6.0.20120810 for i386-unknown-mingw32):
| coVarsOfTcCo:Bind
| cobox{v a6Czs} [lid]
| = cobox{v a6CTr} [lid] `cast`
| (main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
| model{tv tC} [tv]
|
| (main:Darcs.Witnesses.Ordered.FL{tc r1Dy1} prim{tv ty} [tv]
|
| main:Darcs.Witnesses.Ordered.:{tc r1Dyc}
| main:Darcs.Witnesses.Ordered.FL{tc
7.6.1 RC1 panic coVarsOfTcCo:Bind
Hi,
I'm getting the panic below when building darcs 2.8 with GHC 7.6. It'll
take some effort to cut it down or give repro instructions for an
uncut-down version (I needed to hack a lot of underlying packages to be
able to even get as far as doing this build), so could someone confirm
that it's worth it before I do so? I can't spot anything already
reporting this in trac.
Cheers,
Ganesh
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.6.0.20120810 for i386-unknown-mingw32):
coVarsOfTcCo:Bind
cobox{v a6Czs} [lid]
= cobox{v a6CTr} [lid] `cast`
(main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
model{tv tC} [tv]
(main:Darcs.Witnesses.Ordered.FL{tc r1Dy1} prim{tv ty} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1Dyc}
main:Darcs.Witnesses.Ordered.FL{tc r1Dy1}
prim{tv ty} [tv])
ghc-prim:GHC.Types.~{(w) tc 31Q}
main:Darcs.Test.Patch.WithState.WithState{tc r1LL8}
(Sym cobox{v a6CSH} [lid])
main:Darcs.Witnesses.Ordered.FL{tc r1Dy1}
prim{tv ty} [tv]
main:Darcs.Witnesses.Ordered.:{tc r1Dyc} main:Darcs.Witnesses.Order
ed.FL{tc r1Dy1}
prim{tv ty} [tv])
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build failures when hiding non-visible imports
On 17/08/2012 11:18, Simon Peyton-Jones wrote: | Would it be reasonable to change ghc's behavior to treat this | (ie an 'import' statement that hides something that isn't exported) as a | warning instead of an error? Yes, that would be easy if it's what everyone wants. Any other opinions? I don't feel strongly either way, but I'd just argue that if it happens it should happen for 7.6.1 to get maximum benefit. Otherwise packages will still need preprocessor hacks to hide Prelude.catch in the meantime (or to use explicit imports from the Prelude, which would be pretty annoying). Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem with FFI and libsane
On 07/06/2012 12:08, Simon Marlow wrote: I don't completely understand what is going wrong here, but it looks like an interaction between the RTS's use of a timer signal and the libsane library. You can make it work by turning off GHC's timer with +RTS -V0. [..] The signal has always been SIGVTALRM, as far as I can tell. Which is confusing - if the signal had changed, I could understand that being the cause of the difference in behaviour. Perhaps it is just that system calls are being interrupted by the signal more often than they were before, and libsane does not properly handle EINTR. I looked at the strace output and can't see any use of a signal by libsane. I see, thanks. I'll do some digging into libsane and see if I can work out more details. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problem with FFI and libsane
Hi,
I'm having some trouble making Haskell bindings to libsane (a scanner
access library: http://www.sane-project.org/)
When I build the cut down sample of my code (below) with GHC 7.4.1 with
the non-threaded runtime, it hangs at runtime in the call to
c'sane_get_devices (after printing go). Pressing ^C causes it to
continue and print done before exiting.
If I compile with GHC 7.2.2 non-threaded, it doesn't hang, printing
first go then done after a few seconds. That pause is expected, as
it's also seen in the equivalent C version (also below).
If I switch to the threaded runtime, then things go wrong differently.
Most of the time there's a hang after go and after pressing ^C they
just exit immediately, without printing done. This doesn't change
between 7.2.2 and 7.4.1. Occasionally, things do work and I get go
then done.
All these symptoms seem to point to some kind of threading problem, and
I believe that libsane is using pthreads, although ldd doesn't report it
and strace only shows it loading the library.
The platform is Linux x86, and I've reproduced the behaviour on two
different machines (Debian and Ubuntu). I've also tried with GHC
7.4.1.20120508, the most recent i386 snapshot I could fine.
Is there anything obvious I'm doing wrong, or something I could try next?
Cheers,
Ganesh
Haskell code:
{-# LANGUAGE ForeignFunctionInterface #-}
import Foreign.Marshal.Alloc
import Foreign.Ptr
import System.IO
import Foreign.C.Types
foreign import ccall sane_init c'sane_init
:: Ptr CInt - Callback - IO CUInt
type Callback = FunPtr (Ptr CChar - Ptr CChar - Ptr CChar - IO ())
foreign import ccall sane_exit c'sane_exit
:: IO ()
-- the () in the ptr type is incorrect, but in
-- this cut-down example we never try to dereference it
foreign import ccall sane_get_devices c'sane_get_devices
:: Ptr (Ptr (Ptr ())) - CInt - IO CUInt
main :: IO ()
main = do
hSetBuffering stdout NoBuffering
_ - c'sane_init nullPtr nullFunPtr
putStrLn go
ptr - malloc
_ - c'sane_get_devices ptr 0
putStrLn done
c'sane_exit
C code:
#include sane/sane.h
#include stdlib.h
int main()
{
sane_init(NULL, NULL);
puts(go);
const SANE_Device **ptr;
sane_get_devices(ptr, 0);
puts(done);
sane_exit();
}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unit unboxed tuples
On 23/12/2011 13:46, Ian Lynagh wrote: On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote: Arguments Boxed Unboxed 3 ( , , )(# , , #) 2 ( , ) (# , #) 1 0 () (# #) Simple, uniform. Uniform horizontally, but strange vertically! It's worth mentioning that if you want to write code that's generic over tuples in some way, the absence of a case for singletons is actually a bit annoying - you end up adding something like a One constructor to paper over the gap. But I can't think of any nice syntax for that case either. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Proposal to incorporate Haskell.org
Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation ___ Haskell mailing list hask...@haskell.org
Re: [Haskell] Proposal to incorporate Haskell.org
BTW as with the Don's original message about incorporating, I distributed this widely to increase awareness, but please restrict any feedback to haskell-cafe@ and committee@. Sorry for the noise! Ganesh On 16/12/2011 09:08, Ganesh Sittampalam wrote: Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid
encoding and paths, again
Hi, I'm not entirely clear on what the overall situation will be once Simon M's patch to add .ByteString versions to unix is added in GHC 7.4.1. In particular the original problem darcs ran into was with getDirectoryContents in the directory package. That in turn uses the unix package on Posix systems and another code path based on Win32 on Windows (http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/src/System-Directory.html#getDirectoryContents) So a couple of questions: (1) Does Win32 need similar additions? I can't spot any substantial changes to it for Max's PEP383, but I'm not sure if any lower-level library changes might have affected it. (2) What's the recommended way of doing the equivalent of getDirectoryContents for RawFilePath? Do we also need to add raw versins to the directory package? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
Hi Max, On 01/11/2011 10:23, Max Bolingbroke wrote: This is my implementation of Python's PEP 383 [1] for Haskell. IMHO this behaviour is much closer to what users expect.For example, getDirectoryContents . = print shows Unicode filenames properly. As a result of this change we were able to close quite a few outstanding GHC bugs. Many thanks for your reply and all the subsequent followups and bugfixing. The workaround you propose seems a little complex and it might be a bit problematic that 100% roundtripping can't be guaranteed even once your fix is applied. Do you think it would be reasonable/feasible for darcs to have its own version of getDirectoryContents that doesn't try to do any translation in the first place? It might make sense to make a separate package that others could use to. BTW I was trying to find the patch where this changed but couldn't - was it a consequence of https://github.com/ghc/packages-base/commit/509f28cc93b980d30aca37008cbe66c677a0d6f6 ? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
behaviour change in getDirectoryContents in GHC 7.2?
Hi, I'm just investigating what we can do about a problem with darcs' handling of non-ASCII filenames on GHC 7.2. The issue is apparently that as of GHC 7.2, getDirectoryContents now tries to decode filenames in the current locale, rather than converting a stream of bytes into characters: http://bugs.darcs.net/issue2095 I found an old thread on the subject: http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html and some GHC tickets (e.g. http://hackage.haskell.org/trac/ghc/ticket/3300) Can anyone point me at the rationale and details of the change and/or suggest workarounds? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: accessing compilation parameters from template haskell
Would making a template-haskell-ghc package make sense? Might be overkill just for my requirement but there could be other things like support for GHC-specific language extensions that might also logically belong there. On 16/09/2011 08:21, Simon Peyton-Jones wrote: The difficulty here is that the TH library, by design, doesn't depend on GHC. So we can't have a TH function getFlags :: Q DynFlags or (as you suggest, more or less) runTc :: TcM a - Q a because to write those type signatures in Language.Haskell.TH.Syntax you'd need to import GHC. There's no difficulty in *practice*! Q more or less *is* TcM. Still I don't really know how to get around this in a beautiful way. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Ganesh Sittampalam | Sent: 16 September 2011 06:42 | To: GHC users | Subject: accessing compilation parameters from template haskell | | Hi, | | It would be useful to access the current compilation parameters or even | an entire RunGhc monad from inside a Template Haskell splice. Is there | any way to do this? | | The reason I want to do this is I'm using the ghc API at runtime to | dynamically execute code, and I want both the dynamically loaded code | and static code to use a shared runtime module that defines some types | used for communication across the boundary. To guarantee the internal | representations etc are the same, I store the object file of the runtime | during compilation then load it dynamically at runtime - but to make | this work I need to know where the object file is (-odir and -hidir) and | I also need to know or be able to deduce the GHC DynFlags so I can | replicate them at runtime. | | I could also achieve this goal by putting my runtime in a separate | package and installing it first, but that's less self-contained and | would be a pain during development. | | Cheers, | | Ganesh | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
accessing compilation parameters from template haskell
Hi, It would be useful to access the current compilation parameters or even an entire RunGhc monad from inside a Template Haskell splice. Is there any way to do this? The reason I want to do this is I'm using the ghc API at runtime to dynamically execute code, and I want both the dynamically loaded code and static code to use a shared runtime module that defines some types used for communication across the boundary. To guarantee the internal representations etc are the same, I store the object file of the runtime during compilation then load it dynamically at runtime - but to make this work I need to know where the object file is (-odir and -hidir) and I also need to know or be able to deduce the GHC DynFlags so I can replicate them at runtime. I could also achieve this goal by putting my runtime in a separate package and installing it first, but that's less self-contained and would be a pain during development. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On 15/09/2011 15:43, Ian Lynagh wrote: On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote: Provoked the (very constructive) Yesod blog post on Limitations of Haskell, and the follow up discussion, I've started a wiki page to collect whatever ideas we have about the name spacing issue for record fields. http://hackage.haskell.org/trac/ghc/wiki/Records As Simon M said on Reddit, this is something we'd like to fix; but we need a consensus on how to fix it. Re TypeDirectedNameResolution, I would actually prefer it if it were less general. i.e. if you were to write x.f then f would be required to be a record selector. Then there's no need for the If there is exactly one f whose type matches that of x unpleasantness. Instead, the type of x must be inferred first (without any knowledge about the type of f), and then we know immediately which f is being referred to. One benefit of TDNR is to replicate the discoverability of APIs that OO programming has - if x :: Foo then typing x. in an IDE gives you a list of things you can do with a Foo. (Obviously it's not a complete lis for various reasons, but it does allow the author of Foo and others to design discoverable APIs.) So I think we'd be losing quite a bit to force f to be a record selector. Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal to incorporate Haskell.org
On 11/05/2011 10:33, Yitzchak Gale wrote: Don Stewart wrote: The haskell.org committee... has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. Thanks, good news! And thanks for posting to multiple lists for maximum public notification to the community. Can the committee now designate a single list for further discussion please? Sorry about the noise. I think haskell-cafe is the best choice for further discussion. Please, everyone send further followups to any message in this thread to just haskell-c...@haskell.org and commit...@haskell.org, or just to commit...@haskell.org if you want to respond privately. Ganesh (haskell.org committee member) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: weird behaviour of context resolution with FlexibleContexts and TypeFamilies
Hi Dimitrios,
Done: http://hackage.haskell.org/trac/ghc/ticket/4981
BTW although I said in my original email that this happened on GHC 6.12
as well as GHC 7, it looks like that's not the case for the cutdown
example. I'm fairly sure that it happened with my original code; let me
know if it's important to know and I'll go back and check on that.
Cheers,
Ganesh
On 26/02/2011 02:01, Dimitrios Vytiniotis wrote:
Hi Ganesh, you are right Simon's answer is not correct.
The cause of your problem is I believe quite involved -- I think I
know what's going on (Simon: it seems to be
an overlap problem indeed but between a different instance and given
arising from a superclass when trying to
solve a 'silent parameter' wanted) but I can't build the compiler on
my OS X tonight to verify my thoughts.
I will hopefully be able to say more over the weekend. Can you submit
a bug report in the meanwhile?
Or I will do it tomorrow.
Thanks!
d-
*From:* glasgow-haskell-users-boun...@haskell.org
[glasgow-haskell-users-boun...@haskell.org] on behalf of Ganesh
Sittampalam [gan...@earth.li]
*Sent:* Friday, February 25, 2011 4:39 PM
*To:* Simon Peyton-Jones
*Cc:* glasgow-haskell-users@haskell.org; Sittampalam, Ganesh
*Subject:* Re: weird behaviour of context resolution with
FlexibleContexts and TypeFamilies
Hi Simon,
You talk about the timing of application of the instance declaration
instancePatchInspect (PrimOf p)) = Conflict p
but the constraint is actually defined in the class declaration, and I
don't have any instance declarations for Conflict p itself.
classPatchInspect (PrimOf p)) = Conflict p
Does that make a difference to your answer, or do you mean that the
constraint in the class declaration automatically gives rise to the
same behaviour?
Ganesh
On 25/02/2011 09:06, Simon Peyton-Jones wrote:
You are doing something very delicate here, akin to overlapping
instances.
You have an instance
instancePatchInspect (PrimOf p)) = Conflict p
and a function
clever :: (Conflict (OnPrim p), ..) = ...
So if a constraint (Conflict blah) arises in the RHS of clever, the
instance declaration will immediately apply; and then the type check
fails. But if it just so happens to precisely match the provided
constraint (Conflict (OnPrim p)), you want to use the provided
constraint. In effect the type signature and the instance overlap.
Arguably, GHC should refrain from applying the instance if there is
any possibility of a “given” constraint matching. Currently it’s a
bit random; but it’s a very weird situation.
But first, is this really what you intend?
Simon
*From:*glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] *On Behalf Of
*Sittampalam, Ganesh
*Sent:* 24 February 2011 07:41
*To:* glasgow-haskell-users@haskell.org
*Subject:* weird behaviour of context resolution with
FlexibleContexts and TypeFamilies
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 quite confusing - in the
original code joinPatches did something useful and I was trying to
inline the known instance definition. I would have expected it to be
consistent between all three cases, either requiring the context or not.
Is it a bug, or just one of the risks one takes by using
FlexibleContexts?
I've tried this with GHC 6.12.3 and with 7.0.2RC2.
Cheers,
Ganesh
{-# LANGUAGE CPP, TypeFamilies, FlexibleContexts #-}
module Class ( cleverNamedResolve ) where
data FL p = FL p
class PatchInspect p where
instance PatchInspect p = PatchInspect (FL p) where
type family PrimOf p
type instance PrimOf (FL p) = PrimOf p
data WithName prim = WithName prim
instance PatchInspect prim = PatchInspect (WithName prim) where
class (PatchInspect (PrimOf p)) = Conflict p where
resolveConflicts :: p - PrimOf p
instance Conflict p = Conflict (FL p) where
resolveConflicts = undefined
type family OnPrim p
#if VER==1
class FromPrims p where
instance FromPrims (FL p) where
joinPatches :: FromPrims p = p - p
#else
#if VER==2
joinPatches :: FL p - FL p
#else
joinPatches :: p - p
#endif
#endif
joinPatches = id
cleverNamedResolve :: (Conflict (OnPrim p)
,PrimOf (OnPrim p) ~ WithName (PrimOf p))
= FL (OnPrim p) - WithName (PrimOf p)
cleverNamedResolve = resolveConflicts . joinPatches
==
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
Re: weird behaviour of context resolution with FlexibleContexts and TypeFamilies
Hi Simon,
You talk about the timing of application of the instance declaration
instancePatchInspect (PrimOf p)) = Conflict p
but the constraint is actually defined in the class declaration, and I
don't have any instance declarations for Conflict p itself.
classPatchInspect (PrimOf p)) = Conflict p
Does that make a difference to your answer, or do you mean that the
constraint in the class declaration automatically gives rise to the same
behaviour?
Ganesh
On 25/02/2011 09:06, Simon Peyton-Jones wrote:
You are doing something very delicate here, akin to overlapping
instances.
You have an instance
instancePatchInspect (PrimOf p)) = Conflict p
and a function
clever :: (Conflict (OnPrim p), ..) = ...
So if a constraint (Conflict blah) arises in the RHS of clever, the
instance declaration will immediately apply; and then the type check
fails. But if it just so happens to precisely match the provided
constraint (Conflict (OnPrim p)), you want to use the provided
constraint. In effect the type signature and the instance overlap.
Arguably, GHC should refrain from applying the instance if there is
any possibility of a given constraint matching. Currently it's a
bit random; but it's a very weird situation.
But first, is this really what you intend?
Simon
*From:*glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] *On Behalf Of
*Sittampalam, Ganesh
*Sent:* 24 February 2011 07:41
*To:* glasgow-haskell-users@haskell.org
*Subject:* weird behaviour of context resolution with FlexibleContexts
and TypeFamilies
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 quite confusing - in the original
code joinPatches did something useful and I was trying to inline the
known instance definition. I would have expected it to be consistent
between all three cases, either requiring the context or not.
Is it a bug, or just one of the risks one takes by using
FlexibleContexts?
I've tried this with GHC 6.12.3 and with 7.0.2RC2.
Cheers,
Ganesh
{-# LANGUAGE CPP, TypeFamilies, FlexibleContexts #-}
module Class ( cleverNamedResolve ) where
data FL p = FL p
class PatchInspect p where
instance PatchInspect p = PatchInspect (FL p) where
type family PrimOf p
type instance PrimOf (FL p) = PrimOf p
data WithName prim = WithName prim
instance PatchInspect prim = PatchInspect (WithName prim) where
class (PatchInspect (PrimOf p)) = Conflict p where
resolveConflicts :: p - PrimOf p
instance Conflict p = Conflict (FL p) where
resolveConflicts = undefined
type family OnPrim p
#if VER==1
class FromPrims p where
instance FromPrims (FL p) where
joinPatches :: FromPrims p = p - p
#else
#if VER==2
joinPatches :: FL p - FL p
#else
joinPatches :: p - p
#endif
#endif
joinPatches = id
cleverNamedResolve :: (Conflict (OnPrim p)
,PrimOf (OnPrim p) ~ WithName (PrimOf p))
= FL (OnPrim p) - WithName (PrimOf p)
cleverNamedResolve = resolveConflicts . joinPatches
==
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Thu, 9 Dec 2010, Simon Marlow wrote: On 08/12/2010 17:39, Yitzchak Gale wrote: Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. I think that might be a little overoptimistic. The fundamental problem with darcs is that nobody understands the semantics. Until there's a proper semantics that people can understand, I don't think the problems with merging and conflicts can really be fixed. Even if the semantics can be nailed down, there are some difficult UI issues to solve. We're not moving to v2 patches right now because we have enough experience with v1 to know how to avoid the bugs, but I'm less sure we could avoid the bugs in v2. To the darcs folk: do you think this is unfounded paranoia? Sadly, no. On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Opinion on whether we should switch seems to be pretty evenly split at the moment (personally I'm agnostic). Besides that, the main stumbling block is that the GHC tree consists of about 20 repos, with different maintainers, so making it so that a GHC developer only needs to use one VC tool could be tricky. My feeling is that a bridge should be quite feasible and would offer those contributors who want it the opportunity to do their GHC development in git and only use darcs when submitting their final changes or when working in unbridged repos. I'm not too familiar with the structure of the GHC repo but I suspect that only a few of the subrepos are big or active enough that darcs is really painful. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Wed, 8 Dec 2010, Stephen J. Turnbull wrote: Ganesh Sittampalam writes: I think there are three things that can help with this problem: 1) a darcs rebase command. This will give you a nice way to manage the workflow already discussed, and you won't have to squish everything through into a mega-patch. You'll still have to periodically abandon one branch for another though (but I think that's also the case with git rebase). I'm not sure what you mean by abandon. I mean the same as in the git world. The rebased patches have new identities, and if my ideas for tracking the relationship don't work out, they will have no relationship to the old patches. [your very clear explanation of that snipped] I also have some hope, though this is more speculative, of offering a clean way of tracking the relationship between the old branch and the new branch so that any stray patches against the old branch can be cleanly rebased to the new branch later on. As explained above, DAG-based VCSes like git can't do this cleanly (that is one way of expressing the reason why rebase is severely deprecated in some circles), and I don't think git will be able to do so in the near future. OTOH, if Darcs gets rebase but can't handle this, I'd have to count that as a net minus. Recombinant patching is really what Darcs is all about IMO. darcs rebase is essentially about giving up on the recombinant patching because that's not working out for whatever reason. It's primarily intended as an alternative to manually reapplying patches to new branches using diff-and-patch, which is something significant numbers of people have ended up having to do. People generally want/need to do this to avoid conflicts, because: (a) darcs conflict handling can blow up, both because of exponential merges (primarily with v1 patches) and because of bugs (b) the UI for dealing with conflicts isn't really that pleasant and in particular once you've resolved a conflict it's a little painful to see the overall effect of the conflict resolution together with the underlying patch In practice, git rebase needs to be kept private to a single user, and is impractical even if private, if the user has propagated the branch to other local repositories. Because git branching is so lightweight, nobody really sees this as a big problem; throwaway branches are used all the time as interim steps in many operations (eg, git stash). Darcs branches, on the other hand, are much more heavyweight (modulo the work you propose on colocated branches, but that's farther away than rebase is). IMHO YMMV. But I strongly recommend you think carefully about this. Analogies to git rebase are a trap here. It's implemented differently and used to solve different problems from the way rebase is proposed for use in Darcs. My understanding is that one of the main uses for git rebase is for cleaning up history prior to submission. In that regard I think there's a substantial overlap with what darcs rebase is intended for. Thanks for the detailed comments. Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Mon, 6 Dec 2010, Simon Peyton-Jones wrote: I too wish there was a good solution here. I've taken to making dated repos, thus http://darcs.haskell.org/ghc-new-co-17Nov10 When it becomes unusable, I make a brand new repo, with a new date starting from HEAD, pull all the old patches, unrecord them all, rerecord a mega-patch, and commit. This is darcs's primary shortcoming. It is well known, and the darcs folk are working on it. But I don't think they expect to have a solution anytime soon. (Please correct me if I'm wrong.) I think there are three things that can help with this problem: 1) a darcs rebase command. This will give you a nice way to manage the workflow already discussed, and you won't have to squish everything through into a mega-patch. You'll still have to periodically abandon one branch for another though (but I think that's also the case with git rebase). I also have some hope, though this is more speculative, of offering a clean way of tracking the relationship between the old branch and the new branch so that any stray patches against the old branch can be cleanly rebased to the new branch later on. I'm actively working on rebase (with some gaps to refactor the darcs codebase to make working on it easier) and very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it, though there's significant work yet to do. If anyone else wants to try it, please do: see the thread at http://lists.osuosl.org/pipermail/darcs-users/2010-August/024924.html 2) multi-branch repos. We've pretty much agreed we need these; I think the strongest motivation is being able to keep the same build products around when switching branches. No concrete plans, but perhaps the release after next if we can manage it? 3) Better performance when there are conflicts, so you don't have to rebase as often/ever. For this you need a new patch format. GHC is using v1 patches, but darcs also now has v2 patches, which get into exponential merges much less often - but it's still possible, and we know of bugs in the merging which can hit in complex cases (v1 patches also have a few buggy corner cases). You also have to go through an explicit conversion step to switch to v2. I think we need to have another go at figuring out the problem once and for all (i.e. v3) but we don't know for sure how to do this. Something related, but not exactly addressing the problems you all describe is: 4) Better UI around managing conflicts - one frequently requested thing is to be able to see the names of the patches that caused the conflicts. I'm working on this actively (it's also useful for rebase) and I also hope/expect to have this in the next release. Another thing that'll definitely be in the next release is that conflict marks will include the original text as well, so you can work out what changes each side of the conflict made. In my experience that actually makes a huge difference and it's very annoying we didn't do it earlier. and, once we've got better at the basics, 5) we'd love to add new patch types that reduce the number of conflicts you get at all. Some ideas include hunk move patches that track when you move code from place to place, identation patches, and patches that track character changes to an individual line. Again, no timescale, but having refactored some of the core patch code recently it's now much clearer how we could do this. Finally, I think the future holds more hybrid environments where different people use different VCSes and bridge between them. (At least, I hope so, it's the only hope darcs has of staying relevant in the wider world :-). Petr Rockai's recent darcs-fastconvert tool offers incremental darcs-git conversions, which I think should allow people who are happier with git to use that instead and only convert back to darcs to submit their patches. [It may be that previous tools also offered this, I'm not certain.] Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and darcs
Hi Neil, On Tue, 2 Nov 2010, Neil Mitchell wrote: Make sure you are using RC2 of the compiler, from what I remember RC1 required signatures it shouldn't have, or enabled MonoLocalBinds more than it should - RC2 required less signatures. However, your code could well just be heavily using the relevant features. I was using RC2. But darcs uses GADTs globally so MonoLocalBinds is always on. I've now retested with NoMonoLocalBinds properly enabled and I just needed one extra signature. That's quite compelling, but I'm aware it's not considered a reliable feature so I'm not quite sure which way to go. The NPlusKPatterns thing seems to have been a red herring btw, I can't reproduce it now. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1
On Sun, 26 Sep 2010, Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 7.0.1:
http://new-www.haskell.org/ghc/dist/7.0.1-rc1/
This includes the source tarball, installers for OS X and Windows, and
bindists for amd64/Linux and i386/Linux.
Please test as much as possible; bugs are much cheaper if we find them
before the release!
gan...@nevis:~/dataenc$ cabal install regex-posix
Resolving dependencies...
Configuring regex-posix-0.94.4...
Preprocessing library regex-posix-0.94.4...
Building regex-posix-0.94.4...
[1 of 6] Compiling Text.Regex.Posix.Wrap (
dist/build/Text/Regex/Posix/Wrap.hs, dist/build/Text/Regex/Posix/Wrap.o )
SpecConstr
Function `lvl_s2xM{v} [lid]'
has three call patterns, but the limit is 0
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.0.20100924 for x86_64-unknown-linux):
initC: srt_lbl
Let me know if you'd prefer this to be recorded in trac or would like me
to try to cut it down.
Cheers,
Ganesh
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.12.1 and impredicative polymorphism
On Fri, 30 Oct 2009, Sittampalam, Ganesh wrote: 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 using it. At least, I had to enable ImpredicativePolymorphism to successfully build darcs with GHC 6.11 (a snapshot from about February), although the flag is not required with GHC 6.10. I haven't had a chance to try with the RC yet, but will do this weekend. I'll have to check the full details of why it's needed, but from memory I think it can be worked around at the cost of more verbosity by using some newtypes in appropriate places. OK, I confirm the changes are fairly trivial. The main issue is that a couple of functions want to instantiate the argument to IO with a type scheme: restrictBoring :: IO (forall t m. FilterTree t m = t m - t m) The newtype workaround works fine here and doesn't affect too much of the code. In one other place some code had type [(String, Foo)] where Foo is a type synonym for (forall x y . something), but it turned out the nested quantification wasn't required so (forall x y . [(String, something)]) was ok in this case, if a little uglier. (Patch sent to darcs-users) Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
array-0.2.0.0 doesn't build with 6.12rc1
[ 6 of 10] Compiling Data.Array.IO( Data/Array/IO.hs, dist/build/Data/Array/IO.o ) Data/Array/IO.hs:73:13: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:22: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:36: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:74:5: Not in scope: data constructor `Buffer' Data/Array/IO.hs:74:13: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:25: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:36: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:75:4: Not in scope: `bufferEmpty' Data/Array/IO.hs:82:24: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:82:35: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:86:24: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:95:27: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:101:10: Not in scope: `readRawBuffer' Data/Array/IO.hs:125:22: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:31: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:45: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:127:18: Not in scope: data constructor `Buffer' Data/Array/IO.hs:127:26: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:42: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:53: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:135:30: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:142:7: Not in scope: data constructor `Buffer' Data/Array/IO.hs:142:15: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:27: `bufState' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:36: Not in scope: data constructor `WriteBuffer' Data/Array/IO.hs:143:8: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:19: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:34: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:151:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:151:43: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:35: Not in scope: type constructor or class `RawBuffer' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: finalizers on handles
On Tue, 23 Jun 2009, Brandon S. Allbery KF8NH wrote: On Jun 23, 2009, at 09:41 , Simon Marlow wrote: main = do (ih, oh, _, _) - runInteractiveProcess cat [] Nothing Nothing comphszp - hGetContents oh print (length comphszp) -- hClose ih -- with this line they both deadlock Note that you can trigger this in any language; it's a classic beginner error with pipes (see, for example, the documentation for open2/open3 in Perl or Python for other examples). Detecting this in the type system would be an interesting idea, but de facto I think this is a it hurts when I do this. Sure - but it hurts more when in some environments you get away with it and others you don't. Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
finalizers on handles
Hi, I recently spent a while debugging a problem where a program deadlocked in the non-threaded runtime, but ran fine in the threaded runtime, despite the program having no blocking FFI calls, and boiled it down to the following test case: module Main(main) where import System import System.IO import System.Process main = do (ih, oh, _, _) - runInteractiveProcess cat [] Nothing Nothing comphszp - hGetContents oh print (length comphszp) -- hClose ih -- with this line they both deadlock The reason for the deadlock is fairly straightforward; since ih isn't closed before comphszp is fully demanded, no progress can be made. My guess is that the threaded runtime is fine because ih is dead at that point, and the finalizer for ih gets a chance to run, closing ih. 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 non-deterministically. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.10 changes for recursive calls to class instances
Hi,
I have a problem in GHC 6.10 with functions in a class instance calling
other functions in the same class instance. It seems that the dictionary
is freshly constructed for this call, despite being already available.
The reason I care is that I want to memoise some expensive computations
inside the dictionary for each instance. [Obviously I also have to make
sure that the dictionary isn't constructed multiple times by external
callers, but I can make other arrangements to ensure that.]
To see the problem in action, run main from the attached code. In GHC 6.8
and before, this only executes the trace statement once. In GHC 6.10, the
trace statement executes twice, at all optimisation levels.
This seems related to
http://hackage.haskell.org/trac/ghc/ticket/2902, but I'm a little unclear
on whether it's the same problem or not.
Cheers,
Ganesh{-# LANGUAGE ScopedTypeVariables #-}
module RecDict where
import Debug.Trace
class Foo a where
tname :: a - String
mem1 :: a - Int
mem2 :: a - Int
mem2 = let opt = trace (Ouch! Imagine this is really expensive! Called for ++ tname (undefined :: a)) (2 * mem1 (undefined :: a))
in \a - opt
mem3 :: a - Int
instance Foo () where
tname _ = ()
mem1 _ = 0
mem3 _ = 0
data T a = T a
instance Foo a = Foo (T a) where
tname ~(T a) = T ( ++ tname a ++ )
mem1 ~(T a) = 1 + mem1 a
mem3 a = 1 + mem2 a
add :: Foo a = a - Int
add a = mem2 a + mem3 a
main = print $ add (T ())
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: flexible contexts and context reduction
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). Shouldn't the Ord (a, b) context be reduced? To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) implies that, but it's the other way round. Oh yes, I see. Thanks. Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: fundeps help
On Mon, 3 Dec 2007, Simon Peyton-Jones wrote: No, you didn't miss anything. I wouldn't expect anyone to write these types directly. But it can happen: class C a b | a-b instance C Int Bool class D x where op :: forall y. C x y = x - y instance D Int where op = ... In the (D Int) instance, what's the type of op? Well, it must be op :: forall y. C Int y = Int - y And here we know that y=Bool; yet since we don't write the type sig directly we can't say it. So GHC's implementation of fundeps rejects this program; again it can't be translated into System F. Conveniently, this is a good example of my other problem with fundeps :-) I can work around the problem from my first email with an unsafeCoerce, but is there any way I can get around the issue above at the moment in either 6.8 or the HEAD? I actually plan to recast the code in question using associated type synomyms once they're working properly, but would like to be able to make some progress now. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fundeps help
Hi,
I'm trying to understand what fundeps do and don't let me do. One
particular source of confusion is why the following program doesn't
typecheck:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
module Fundeps where
class Dep a b | a - b, b - a
conv :: (Dep a b1,Dep a b2) = b1 - b2
conv = id
{- end of program -}
It seems as if inferring that b1 = b2 is precisely what improvement is
about, but I'm not really sure when GHC actually applies that. Is there
any documentation of that? I've read Mark Jones' paper, the haskell-prime
wiki entry about Fundeps and the GHC manual but am still rather lost.
Cheers,
Ganesh
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
On Wed, 21 Nov 2007, Alex Jacobson wrote: Simon Marlow wrote: Alex Jacobson wrote: 1. just using : at the prompt caused a reload. Now you have to type :r. Interesting, I was not aware of that behaviour, so probably fixed it by accident :) Yeah, Igloo said the same thing. Everyone I talked to about the feature didn't know about it until I pointed it out. If it was an accident, it was still a really useful feature and would love to have it back. I knew about it too, though I'd assumed that it repeated the previous : command. It's just that ':r' is the only command I ever repeat. I'd quite like it back too, in either form. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
confusing GADT/scoped type variables behaviour
Hi,
I'm having some trouble writing code that uses GADTs. I finally got
something that is portable between GHC 6.6 and 6.8, but I don't really
understand what's going on, and I'm a bit unhappy with the number of type
signatures required.
I'll explain them with a series of cut-down examples below, so please
forgive the gratuitous beta-redexes.
My testing has been with GHC 6.6 and 6.8.0.20070921, but I believe from
more limited testing that 6.6.1 behaves the same as 6.6.
My first program works fine with both GHC 6.6 and 6.8:
{-# OPTIONS_GHC -fglasgow-exts #-}
module GADT where
data C x y where
C :: P x y - C x x
data P x y where
P :: Q x y - P x y
data Q x y where
Q :: Q x y
data D x y where
D :: C y z - D x z
f :: forall x y . D x y - ()
f (D (C p))
| P q - (\p - p) p
= case q of
Q - ()
{- end of program -}
However, when I change it slightly to make the lambda expression inspect
the structure of p:
{-# OPTIONS_GHC -fglasgow-exts #-}
module GADT where
data C x y where
C :: P x y - C x x
data P x y where
P :: Q x y - P x y
data Q x y where
Q :: Q x y
data D x y where
D :: C y z - D x z
f :: forall x y . D x y - ()
f (D (C p))
| P q - (\p@(P a) - p) p
= case q of
Q - ()
{- end of program -}
it continues to work with 6.6, but 6.8 complains that q has a wobbly type
and I should add a type annotation.
So, I do so, also adding one to the original pattern for p otherwise my
type variables aren't in scope:
{-# OPTIONS_GHC -fglasgow-exts #-}
module GADT where
data C x y where
C :: P x y - C x x
data P x y where
P :: Q x y - P x y
data Q x y where
Q :: Q x y
data D x y where
D :: C y z - D x z
f :: forall x y . D x y - ()
f (D (C (p :: P w z)))
| P q :: P w z - (\p@(P a) - p) p
= case q of
Q - ()
{- end of program -}
Fine with 6.8, but now 6.6 is unhappy. The type variable 'w' is actually
the same as 'y', and 6.6 seems to have noticed this fact and says I should
have given them the same name.
So, I do so:
{-# OPTIONS_GHC -fglasgow-exts #-}
module GADT where
data C x y where
C :: P x y - C x x
data P x y where
P :: Q x y - P x y
data Q x y where
Q :: Q x y
data D x y where
D :: C y z - D x z
f :: forall x y . D x y - ()
f (D (C (p :: P y z)))
| P q :: P y z - (\p@(P a) - p) p
= case q of
Q - ()
{- end of program -}
Now 6.6 is happy. But 6.8 doesn't believe they are the same, and rejects
it. I finally got it to work with both by removing the forall in the
signature of f:
{-# OPTIONS_GHC -fglasgow-exts #-}
module GADT where
data C x y where
C :: P x y - C x x
data P x y where
P :: Q x y - P x y
data Q x y where
Q :: Q x y
data D x y where
D :: C y z - D x z
f :: D x y - ()
f (D (C (p :: P y z)))
| P q :: P y z - (\p@(P a) - p) p
= case q of
Q - ()
{- end of program -}
But, I don't really understand why this is so. I guess the 'y' in the
outer signature is no longer a scoped type variable, so 6.6 doesn't
complain, and is no longer the same as the inner 'y', so 6.8 doesn't
complain, but it all feels a bit unsatisfactory.
So, is there a good explanation of the errors from 6.8? Is 6.8 behaving
as expected?
Finally, ideally I'd like not to have any type signatures in the body of f
- is this feasible with 6.8 like it was with 6.6?
Cheers,
Ganesh
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
segfault/massive memory use when using Data.Bits.shiftL
Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, 28 Feb 2005, Remi Turk wrote: On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large... Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge information.) My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that. I apologise for thinking this was a bug :-) Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
readline package in GHC 6.0.1 on Windows
Hi, I notice that the readline package is missing from the Windows MSI build of GHC 6.0.1. Is this deliberate and/or a fundamental limitation of the Windows platform? Would I have to/be able to make my own Cygwin-based build to get it? Cheers, Ganesh ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
