Re: GHC 7.8 release?
On Fri, Feb 08, 2013 at 02:28:20PM +, Simon Marlow wrote: > [..] > So I think, if anything, there's pressure to have fewer major > releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was > 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're > getting too efficient at making releases! > > My feeling is that this pace is too fast. > [..] The GHC versions appear too fast (last 13 years). If asked, I would ask to make them to appear 5 times slower. Regards, -- Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
This is copying to the list my reply to Simon: On Thu, Jan 03, 2013 at 12:57:02PM +, Simon Peyton-Jones wrote: > OK I have tested with today's GHC 7.6.2, which is very slightly later > than the release candidate. > > When I add (EuclideanRing (UPol k)) to the signature for cubicExt, the > whole of demotest compiles. So that works. > Also ghc $doconCpOpt --make Main ./Main must end with "No errors detected", and take not more than 4 sec on a 2 GHz machine (for suppose that an overlap is resolved unluckily for the cost, so that the time becomes, say 60 sec). > Your misconception is here: > > | c) Pol3_ has > |instance (LinSolvRing (Pol a), CommutativeRing a) => > | LinSolvRing (UPol (Pol a)) > |But this does not overlap with Field k => LinSolvRing (UPol k). > | > |Because Pol a is never of a Field nor of EuclideanRing. > > When matching instances, GHC does not take account of the context of the > instance. Say you have > [..] I knew this, and have forgotten. Thank you. > If you don't care which of the overlapping instances is picked, then > you can use -XIncoherentInstances. But you have to set that flag at > the *instance declaration* not at the *use* of the instance. In this > case it would be the instance for LinSolvRing (UPol k) Probably, this will work good in one place where this instance is used, and work bad in another place. In the papers on algorithmic algebra the authors often compute some foo for a domain T, and consider various methods for this computation, and often a method is defined by the choice of the instance derivation. And the author writes: apply the method defined by this and this instance construction, this costs, say, O(n^3) bit operations, and so on (literally, the word `instance' is not written). So, there is not a problem of specifying the overlap resolving in papers and lectures, this is done easily. But Haskell+Glasgow does not provide a sufficient language construct for such a resolving. It has the rule of a "substitutionally more special instance". Probably, something appropriate can be added to this rule. Anyway, I shall wait for ghc-7.6.2, and see. Thanks, -- Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
On Wed, Jan 02, 2013 at 11:27:15PM +, Simon Peyton-Jones wrote:
> I made a second mistake. I meant (LinSolvRing (UPol k)). Apologies.
>
> | > I don't know why 7.4 accepts it, but I'm not inclined to investigate...
> | > looks like a bug in 7.4.
> |
> | ghc-7.4.1 may use a special trick, but is correct.
>
> I don't understand your explanation. What is wrong with this reasoning?
>
> 1. The call to upEucRing in cubicExt gives rise the constraint
> (LinSolvRing (UPol k))
> Corect?
>
> 2. There are two overlapping instances for (LinSolvRing (UPol k)),
> defined in UPol2_ and UPol3_
> Correct?
>
> 3. So GHC cannot solve the constraint using an instance declaration.
> Correct?
>
> 4. The type signature provides
> (Field k, FactorizationRing (UPol k))
>but neither is enough to satisfy LinSolvRing (UPol k).
>Correct?
>
> 5. Therefore we must add LinSolvRing (UPol k) to the signature.
>
> If you believe that the function should typecheck as-is, please explain
> how to deduce (LinSolvRing (UPol k)) from
> (Field k, FactorizationRing (UPol k)).
1. I try adding `, LinSolvRing (UPol k)' to the sig of cubeExt.
Now, ghc-7.6.1.20121207
builds docon-2.12 but does not compile the demonstration of T_cubeext.hs
(where cubicExt is)
-- with {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
prepended to the module.
Can you, please, reproduce this in ghc-7.6.1.20121207 ?
Because
a) the problem is in porting to a fresh stable GHC version,
b) ghc-7.6.1.20121207 is announced to become a fresh ghc-7.6.2,
and it asks for testing,
c) if I use an older version, then, why, I could simply remain with
ghc-7.4.1.
2. Now suppose that a fresh GHC is fixed, and the point (1) works.
Adding `, LinSolvRing (UPol k)' is not an error.
But is an awkward algebraic statement.
For example, one can formulate
"for all integer p > 2 such that p is prime and p is odd,
it holds Foo(p)".
Adding "and p is odd" is not an error, but looks awkward, because it is
derived from (p > 2, p is prime) according to previous theory.
This reduces redability of the text, because the reader starts to think
that he is missing something subtle.
Similarly, LinSolvRing (UPol k) is derived in cubicExt from
cubicExt and from the proper DoCon.
The matter is that the algorithm (instance) for this LinSolvRing (UPol k)
is derived in multiple ways -- overlapping instances.
3. For this particular case, I agree to tell to GHC:
"choose any derivation way you like".
Because a) I know that the needed final result part does not depend on
this choice (even though the algoritms differ),
b) the cost difference will not be great.
How can I tell this to GHC -- with respect to only this function signature,
or maybe, only to this module ?
4. Probably, the rule of the substitutional instance specialization in
Haskell+Glasgow is not enough to follow algebra.
Why not give the user an additional way to choose the derivation?
For example, let there be the instances I, II, III, IV, and the instance
(Foo T) is derived from I, II, III, IV in multiple ways.
The programmer writes the signature
f :: (..., (Foo T, using {II, III}, notUsing {I, IV})) => ...
which means to consider for (Foo T) only those derivations which use
{II, III} and do not use {I, IV}.
I do not know, may be I am missing something.
5. Now, I specify how LinSolvRing (UPol k) is derived in the existing
Haskell+Glasgow language.
DoCon = Proper-DoCon + demo;cubicExt is a part of demo.
First, Proper-DoCon is installed -- this works.
And cubicExt is not compiled.
Proper-DoCon includes:
GCDRing a and EuclideanRing a are superclasses for Field a, (I)
class (GCDRing a, LinSolvRing a) => EuclideanRing a where ... (II)
instance GCDRing a => GCDRing (UPol a) where ...(III)
instance Field k => EuclideanRing (UPol k) where ... (IV)
instance EuclideanRing a => LinSolvRing (UPol a) where ...(V)
(in Pol2_.hs)
Each of these has a very useful algebraic meaning.
Now, GHC starts to compile cubicExt. And there
Field k => LinSolvRing (UPol k)
is derived from I -- V in at least two ways, and may be there are
even more of them.
Algebraically, these overlaps are all right, they are in the nature,
these derivations give equivalent results.
But one may insist: "choose the way, because the algorithms are different,
and the computation cost may differ".
For example, for
Field k => LinSolvRing (UPol k),
I would choose this way:
"Field k is declared.
Euclidean is a superclass for Field by (I).
hence there is the instance Euclidean k.
hence there is the instance LinSolvRing (UPol k)
by V with a := k.
"
And Haskell+Glasgow sees this derivation surely.
In the algebra textbooks
Re: DoCon and GHC
On Wed, Jan 02, 2013 at 08:23:37PM +, Simon Peyton-Jones wrote: > | > The solution is to add (EuclideanRing k) to the type sig of cubicExt. > | > Then it compiles all the way up to the top. > | > | But the DoCon declares > |class (EuclideanRing a, FactorizationRing a) => Field a > | > | (EuclideanRing is a superclass for Field), > | and the test declares > | cubicExt :: (Field k, FactorizationRing (UPol k)) => > | k -> k -> Domains1 k -> (Domains1 (E k), [E k], k -> E k) > | > | So, why the compiler does not `extract' EuclideanRing k from Field k > > I made a mistake. I should have said "add (EuclideanRing (Pol k)) to the > type sig of cubicExt". > > GHC can't extract > EuclideanRing (Pol k) from Field k > except by using one of the two (overlapping) instances. > > I don't know why 7.4 accepts it, but I'm not inclined to investigate... > looks like a bug in 7.4. ghc-7.4.1 may use a special trick, but is correct. > I should have said "add (EuclideanRing (Pol k)) > to the type sig of cubicExt". (1) UPol is for an Univariate Polynomial, and Pol is for an Multivariate Polynomial (more generic). (2) DoCon declares Field k => EuclideanRing (UPol k). (3) DoCon does not have the instance Field k => EuclideanRing (Pol k), because it is not correct in algebra. Haskell+Glasgow can not derive EuclideanRing (Pol k) from Field k in the DoCon code. (4) In cubicExt, Haskell+Glasgow derives a weaker instances: LinSolvRing (Pol k), LinSolvRing (Pol (UPol k)), LinSolvRing (UPol (Pol k)) -- and this is sufficient. This is the intension of DoCon + cubicExt, and ghc-7.4.1 supports this (may be, by some tricky designп, I do not know). (5) I can add EuclideanRing (UPol k) to the sig of cubicExt (even though Haskell+Glasgow must derive it), but I expect that this would not help. (6) I can not add EuclideanRing (Pol k) to the sig of cubicExt, because this is not correct by the algebraic design. cubicExt indeed uses rather a complicated set of instances. I do not know, may be I need to think of how to reorganize the design for porting it to ghc-7.6.2. ghc-7.4.1 did the job correctly, and it is difficult to change the coresponding part of the DoCon design. And if you happen to find how to meet (1) -- (6), then I would not need to re-design the thing. Regards, -- Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DoCon and GHC
On Wed, Jan 02, 2013 at 05:21:43PM +, Simon Peyton-Jones wrote:
> Serge
>
> That's odd. I've tried with both 7.6 and HEAD, and both fail on T_cubeext
> thus:
> T_cubeext.hs:102:10:
> Overlapping instances for LinSolvRing (UPol k)
> arising from a use of `upEucRing'
> Matching instances:
> instance [overlap ok] EuclideanRing a => LinSolvRing (UPol a)
> -- Defined in `docon-2.12:Pol2_'
> instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =>
> LinSolvRing (UPol (Pol a))
> -- Defined in `docon-2.12:Pol3_'
> (The choice depends on the instantiation of `k'
> To pick the first instance above, use -XIncoherentInstances
> when compiling the other instance declarations)
> In the expression: upEucRing unA Map.empty
> In an equation for `dA': dA = upEucRing unA Map.empty
>
> I am using ghc-7.6 from Dec 3 (ie *later* than the released GHC 7.6.1),
> so perhaps the difference in error message is due to a bug in 7.6.1 that's
> fixed in my version. I suggest you use the 7.6.2 release candidate.
Yes, the candidate of 7.6.1.20121207
> Anyway, the error message looks entirely legitimate. It really does
> matter how 'k' is instantiated! I have no idea how it compiled before.
ghc-7.4.1 compiles everything in DoCon, and it is the last such version.
> The solution is to add (EuclideanRing k) to the type sig of cubicExt.
> Then it compiles all the way up to the top.
But the DoCon declares
class (EuclideanRing a, FactorizationRing a) => Field a
(EuclideanRing is a superclass for Field),
and the test declares
cubicExt :: (Field k, FactorizationRing (UPol k)) =>
k -> k -> Domains1 k -> (Domains1 (E k), [E k], k -> E k)
So, why the compiler does not `extract' EuclideanRing k from Field k
?
Regards,
--
Sergei
> | -Original Message-
> | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-
> | bugs-boun...@haskell.org] On Behalf Of Serge D. Mechveliani
> | Sent: 21 December 2012 18:46
> | To: Simon Peyton-Jones
> | Cc: glasgow-haskell-b...@haskell.org
> | Subject: Re: DoCon and GHC
> |
> | On Fri, Dec 21, 2012 at 01:45:04PM +, Simon Peyton-Jones wrote:
> | > OK, do this
> | >
> | > * {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
> | >
> | > * import Categs( Domains1 )
> | >
> | > * Add type sig for dP'
> | > dP' :: (LinSolvRing (Pol a), CommutativeRing a) => Domains1 (Pol
> | > a)
> | >
> | > Then it compiles.
> | >
> | > You are very close to the edge of what can be done!
> |
> |
> | It works. Thank you.
> |
> | There remains only a single unlucky module: T_cubeext.
> | The test demotest/Main works with exception of T_cubeext, but I need
> | T_cubeext.cubicExt to work.
> |
> | Please, continue the test with
> |
> | make install
> | cd demotest
> | ghc $doconCpOpt --make Main
> |
> | (for $doconCpOpt =
> | -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
> | -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
> | -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
> | -XTypeSynonymInstances -XFlexibleInstances -XOverlappingInstances ).
> |
> | It reports
> |
> | --
> | ...
> | T_cubeext.hs:102:20:
> | Could not deduce (k ~ k1)
> | from the context (Field k, FactorizationRing (UPol k))
> | bound by the type signature for
> | cubicExt :: (Field k, FactorizationRing (UPol k)) =>
> | k -> k -> Domains1 k -> (Domains1 (E k), [E
> | k], k -> E k)
> | at T_cubeext.hs:(79,13)-(80,69)
> | or from (Field k1, FactorizationRing (UPol k1))
> | bound by the type signature for
> | unA :: (Field k1, FactorizationRing (UPol k1)) => UPol
> | k1
> | at T_cubeext.hs:101:9-56
> | `k' is a rigid type variable bound by
> | the type signature for
> | cubicExt :: (Field k, FactorizationRing (UPol k)) =>
> | k -> k -> Domains1 k -> (Domains1 (E k), [E k],
> | k -> E k)
> | at T_cubeext.hs:79:13
> | `k1' is a rigid type variable bound by
> |the type signature for
> | unA :: (Field k1, FactorizationRing (UPol k1)) => UPol k1
> |at T_cubeext.hs:101:9
> | Expected type: Domains1 k1
> | Actual type: Domains1 k
> | In the s
Re: divRem by `-' performance
On Thu, Oct 18, 2012 at 01:54:45PM -0400, Albert Y. C. Lai wrote: > On 12-10-18 05:24 AM, Serge D. Mechveliani wrote: >> And concerning this example: I am not even sure now that it worths to >> setting $! there. >> Because I deliberately program qRem as returning a pair (quot, rem), >> and do not program a separate function for rem. And to obtain rem, >> one applies snd (qRem n m), and due to laziness, quot does not >> spend the cost. I do not know, may be, using $! may damage this style. > > snd (quot, rem) does not spend the arithmetic cost of quot, but spends > the memory cost of quot. Memory cost is not just occupation of memory, > but also writing of memory and computing of addresses, which is not > exactly cheaper than arithmetic. But in this example of qRem the time is almost so as if quot was not computed. Probably, the coefficient of this expense is small. On the other hand, an extra memory occupation also often causes slowing down of all the environment program, because this occupation approaches garbage collection. I wonder whether it worths to return some strictness annotations. Regards, Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: divRem by `-' performance
On Wed, Oct 17, 2012 at 07:00:38PM +0300, Roman Cheplyaka wrote: > * Serge D. Mechveliani [2012-10-17 19:37:38+0400] > > But it is generally difficult for me to admit that sometimes it is > > desirable to use strinctess annotation. > > I programmed DoCon for 6 years, and it does not have any bit of > > strictness annotation, and I always had an impression that it is all > > right with performance. > > Yeah, I was also surprised that this is news to you :) > > > And now it occurs that setting $! in some places may make many parts > > of it somewhat 100 times less expensive > > -- ? > > Somehow difficult to admit. > > Laziness is subtle. Sometimes you make an innocent change to a program, > but it changes the time when things are evaluated, and that affects > memory/performance significantly. > I was always aware of all these effects. I deliberately avoided any strictness annotation. And the whole result has a reasonable performance. But then, I forget it, each time, and start to think "everything is all right". This lasts till the next unlucky example, as the above qRem. And each time I recall of unneeded laziness. And concerning this example: I am not even sure now that it worths to setting $! there. Because I deliberately program qRem as returning a pair (quot, rem), and do not program a separate function for rem. And to obtain rem, one applies snd (qRem n m), and due to laziness, quot does not spend the cost. I do not know, may be, using $! may damage this style. Another objection against strictess annotation is that they make difficult to transform the code at an early stage of compilation. Regards, Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: divRem by `-' performance
On Wed, Oct 17, 2012 at 06:17:28PM +0300, Roman Cheplyaka wrote: > * Serge D. Mechveliani [2012-10-17 19:02:37+0400] > > People, > > consider the following contrived program for division with remainder: > > > > > > qRem :: Int -> Int -> (Int, Int) > > qRem m n = if m < 0 || n <= 0 then error "\nwrong arguments in qRem.\n" > >else qRem' 0 m > >where > >qRem' q r = if r < n then (q, r) else qRem' (succ q) (r - n) > > You need to force evaluation of 'q' here, otherwise it becomes a growing > chain of 'succ' applications. > > E.g. > > qRem' q r = if r < n then (q, r) else (qRem' $! succ q) (r - n) This looks as a natural explanation. But it is generally difficult for me to admit that sometimes it is desirable to use strinctess annotation. I programmed DoCon for 6 years, and it does not have any bit of strictness annotation, and I always had an impression that it is all right with performance. And now it occurs that setting $! in some places may make many parts of it somewhat 100 times less expensive -- ? Somehow difficult to admit. Regards, Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
divRem by `-' performance
People, consider the following contrived program for division with remainder: qRem :: Int -> Int -> (Int, Int) qRem m n = if m < 0 || n <= 0 then error "\nwrong arguments in qRem.\n" else qRem' 0 m where qRem' q r = if r < n then (q, r) else qRem' (succ q) (r - n) main = putStr $ shows (qRem n 5) "\n" where e = 25 n = 2^e Compilation in ghc-7.4.1 : ghc --make -O -rtsopts Main Rinning:time ./Main +RTS -K.. -M.. -RTS For e = 25, it takes the minimum of -K80m -M280m (on my Linux Debian machine). Is not this memory eagerness strange? Regards, Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
read-Int implementation
Who can tell, please, how read string :: Integer is implemented in ghc-7.4.1 ? Is it linked from the GMP (Gnu Multi-Precision) library? It is suspiciosely fast :-) In my test on 10^5 strings of length l = 5, 20 it shows the cost order in l less than 1, as if it was O(log(l)), or O(squareRoot(l). This is even despite that the very forming of the string list by concat and by take l0Exp (strs l) seems to have large overhead. The impression is that I am missing something. Regards, -- Sergei mech...@botik.ru - main = putStr (shows resSum "\n") where m = 1 :: Int -- edit this multiplicity: 1, 4 ... digits = (if m == 1 then id else reverse) ['0' .. '9'] :: [Char] l0= 5 :: Int -- first length l0Exp = (10 :: Int)^l0 l = l0 * m -- second length strs :: Int -> [String] -- all digit strings of length n strs n = if n == 0 then [""] else concat [map (d :) (strs (pred n)) | d <- digits] strings = strs l segm= if m == 1 then strings elsetake l0Exp strings -- length segm is always 10^l0 resSum = sum [read str :: Integer | str <- segm] -- testPairs = [(str, read str :: Int) | str <- strings] -- correctness testing > ghc -O2 --make Main > time ./Main ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
`unregisterised' performance
Dear GHC team, I have compared for performance on DoCon of ghc-7.4.1 registerised and unregisterised, both made from source by ghc-7.4.1 (Debian Linux, GenuineIntel, Intel(R) Core(TM)2 CPU), DoCon and its test compiled under -O (-O2 is not better than -O). `registerised' is 5.4 times faster in building DoCon, is 3 times faster in running the DoCon test, produces 1.7 times smaller .a library file for DoCon. All right. Please, keep on supporting the portable (via-C) branch. Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unregisterised and -prof
Dear GHC team, For some reason ghc-7.4.1-unregisterised cannot build random-1.0.1.1 -- unlike ghc-7.4.1-default. This is for ghc-7.4.1 built from source by ghc-7.4.1 on Debian Linux, i386-uknown. 1. I build ghc-7.4.1 from source under the default flags, by ghc-7.4.1, under configure --prefix=/home/mechvel/ghc/7.4.1/inst 2. Build ghc-7.4.1 from source by new by ghc/7.4.1/inst as unregisterised by setting configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis , --- setting BuildFlavour = unreg in mk/build.mk by un-commenting this line. 3. Build random-1.0.1.1 by ghc of 7.4.1/inst by ghc --make Setup ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/inst/lib/ghc-7.4.1 -p ./Setup build -v ./Setup haddock ./Setup install -v It is built all right. 4. Build random-1.0.1.1 by new by ghc/7.4.1/instUnregis by ghc --make Setup ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p ./Setup build -v It reports --- scico:~/ghc/random/random-1.0.1.1> ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p Configuring random-1.0.1.1... scico:~/ghc/random/random-1.0.1.1> ./Setup build -v creating dist/build creating dist/build/autogen Building random-1.0.1.1... Preprocessing library random-1.0.1.1... Building library... creating dist/build /home/mechvel/ghc/7.4.1/instUnregis/bin/ghc --make -package-name random-1.0.1.1 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.5.0.0-c8e7184681d410015e93df85fc49e9dd -package-id time-1.4-3e186a51d3674e5d65b5a7925db3d3a7 -O -O2 -XHaskell98 -XCPP System.Random [1 of 1] Compiling System.Random( System/Random.hs, dist/build/System/Random.o ) /home/mechvel/ghc/7.4.1/instUnregis/bin/ghc --make -package-name random-1.0.1.1 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.5.0.0-c8e7184681d410015e93df85fc49e9dd -package-id time-1.4-3e186a51d3674e5d65b5a7925db3d3a7 -O -O2 -XHaskell98 -XCPP System.Random -prof -hisuf p_hi -osuf p_o System/Random.hs:97:8: Could not find module `Numeric' Perhaps you haven't installed the profiling libraries for package `base'? Use -v to see a list of the files searched for. scico:~/ghc/random/random-1.0.1.1> Should I set something more in mk/build.mk than un-commenting the line #BuildFlavour = unreg ? Please, what I am missing? Thanks, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unregisterized
On Mon, Feb 06, 2012 at 02:33:53PM +0100, Karel Gardas wrote: > [..] > I would recommend to start here: > http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised > Thank you. Probably, there is something like an error on http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised : " To do an unregisterised build, add the following to your mk/build.mk file: GhcUnregisterised=YES GhcWithNativeCodeGen=NO SplitObjs=NO " Because in ghc-7.4.1, mk/build.mk.sample contains [..] ifeq "$(BuildFlavour)" "unreg" GhcUnregisterised= YES GhcWithNativeCodeGen = NO [..], and the user rather needs to find and un-comment the line #BuildFlavour = unreg Right? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unregisterized
People, Please, where the build guide (.pdf, .html) can be download from? Does the source GHC distibution include the build guide? Does the GHC user_guide include the build guide? If not, then -- why? How to build unregisterized ghc-7.4.1 from source? (For many years I read "registerized" in the GHC related messages as "registered" and wondered of why do they care for a user to register a build!) Thanks, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
On Sun, Feb 05, 2012 at 09:09:58PM +0100, Krzysztof Skrz??tnicki wrote: > GHC code still depends on RTS code (written in C by the way) which has to > be ported to a specific platform first. Native code generator offers > 'registered' and 'unregistered' builds. The first are aware of specific > register layout of a architecture. You can find more rationale why it has > been removed somewhere on GHC wiki or mailing lists. > > I think you might be interested in JHC: http://repetae.net/computer/jhc/ > > By design it compiles Haskell code to efficient C code which is quite easy > to read and hack further. Cross compilation is supported and easy too. The > compiler is somewhat experimental but can handle quite a few programs. > I need a reliable portability for ages for the Haskell applications written in Haskell-2010 + Ext, where Ext = Overlapping instances + Multiparametric classes (as in GHC). In particular, my DoCon is such an application. And no Haskell tool was able to compile DoCon except GHC (I tested this in 1995 - 2000). And now GHC somehow seems to deviate from portability (if I am not missing something, I do not know of the GHC technology details). I suspect that a reliable portability can be done mainly by writing in C an interpreter of the Core language of GHC (no matter if it occurs even 10 times slower). Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
via-C
Dear GHC team, I cannot understand why do you remove the C stage in GHC. To my mind: let the result be 3 times slower, but preserve the C code. Because it works everyhere, and there is no real need to rewrite the same program separately for all the existing processors (which number may become, for example, 11000). I am naive, and am not a specialist. But only an invariant program ever has sense. Has the modern GHC a sensible compilation result level to be observed (documented?) (graph rewriting code, or like this) ? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -C in 7.4.1
Dear GHC team, I needed to look into the C code made by ghc-7.4.1 (made from source by 7.0.1 on Debian Linux) for module TT (dropCWhile) where dropCWhile :: (Char -> Bool) -> [Char] -> [Char] dropCWhile p xs = case xs of []-> [] x: ys -> if p x then dropCWhile p ys else xs And applied ghc -C -O TT.hs It reports --- addFlag by -C on the commandline: Warning: The -fvia-C flag does nothing; it will be removed in a future GHC release ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): pipeLoop: at phase As but I wanted to stop at phase HCc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug --- 1. A bug report. 2. How to see this C code? What GHC version shows it? If you have such a version installed, can you, please, send me the C code? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.4.1-candidate-2
Dear GHC team, I have tested ghc-7.4.0.20120126 on Linux Debian, i-386-like by the following tests. 1. Making it by ghc-7.4.0.20111219. 2. Making it by itself. 3. Making random-1.0.1.1. 4. Making and running the DoCon-2.12 test. 5. Making and running an example under DoCon-2.12 under -prof (one point of SCC, without careful investigation). It looks all right. Notes - Making each new ghc version now needs also re-make of Ramdom before making DoCon. In ghc-7.4.0.20111219 the minimal `-M' for the DoCon test running is -M2600k, In ghc-7.4.0.20120126 it is -M2400k; and the time is 3.6 sec instead of 3.8, and ghc-7.4.1 has the same measure results as ghc-7.4.0.20120126. Reards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2
On Fri, Jan 27, 2012 at 11:15:46PM +, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 7.4.1: > > http://www.haskell.org/ghc/dist/7.4.1-rc2/ > The first candidate or the second? (for the date is Jan 27). Is ghc-7.4.0.20111219 the first candidate? Also people already reported a couple of bugs for 7.4.1-rc2/. So, is there going to be the third candidate? If not, then I'll, probably, have to test this second candidate (if it is second). Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: named pipes
To my
>> Dear GHC team,
>> I am testing the IO operations of GHC with the Unix named pipes
>> [..]
Albert Y. C. Lai writes on 19 Jan 2012
> Main.hs does not open fromA at all. (fromA_IO is dead code.) This causes
> fifo2.c to be hung whenever it opens fromA. From the man page of mkfifo(3)
> on Linux:
> "Opening a FIFO for reading normally blocks until some other process opens
> the same FIFO for writing, and vice versa. See fifo(7) for nonblocking
> handling of FIFO special files."
I see now. Thank you.
The intitial example was with a real usage of toA and fromA, and it did
not work as expected. Then, I simplified it, but just missed the point
that ./Main does not really open fromA.
Now, I provide below the initial example.
Can people explain, please, why it performs so?
> In the sister thread in haskell-cafe, the addition of unsafePerformIO
> throws further disorder into these highly order-sensitive operations.
By the way, can you respond (if not to `glasgow' then to mech...@botik.ru)
to my last simple and concrete question to cafe on the subject of
unsafePerformIO ?
Anyway, the below example is free of unsafePerformIO.
And I need to delay the remaining questions on unsafePerformIO
(for myself and maybe, for `cafe') until the current example is fixed.
Regards,
--
Sergei
mech...@botik.ru
I am testing the IO operations of GHC with the Unix named pipes --
(in ghc-7.01 under Debian Linux).
In the below example,
the pipe pair are created by > mkfifo toA
> mkfifo fromA,
`main' in Main.hs opens toAfor writing,
opens fromA for reading,
outputs "A1" to toA,
inputs the respond string str' from fromA,
prints str' to the screen.
The C program fifo2
opens toAfor reading,
opens fromA for writing,
inputs a string str from toA,
converts str to the lower case, obtaining str'
outputs str' to fromA.
Main.hs is built by ghc --make Main,
The C program is built by gcc -o fifo2 fifo2.c
First, ./fifo2 is run on terminal-2,
then./Mainis run on terminal-1.
The effect is that fifo2(on terminal-2) hangs silent, and
Main.hs (on terminal-1) reports only
"str1 --> hFlush done", and then hangs.
This contradicts to that ./Main must print str' to the screen.
The modules are as follows.
-- Main.hs -
import System.IO (IOMode(..), IO(..), Handle, openFile, hPutStr,
hFlush, hGetLine)
dir = showString "/home/mechvel/ghc/notes/npipe/"
toA_IO = openFile (dir "toA") WriteMode :: IO Handle
fromA_IO = openFile (dir "fromA") ReadMode
axiomIO :: Handle -> Handle -> String -> IO String
axiomIOh1h2str =
do
hPutStr h1 str
hFlush h1
putStr "hFlush done\n"
str' <- hGetLine h2
putStr (concat ["hGetLine -> ", str', "\n"])
return str'
main = do
h1 <- toA_IO
h2 <- fromA_IO
putStr "str1 --> "
str1' <- axiomIO h1 h2 "A1"
putStr (str1' ++ "\n")
--- fifo2.c -
#include
#include
#define BOUND 64
static char str[BOUND];
main()
{
int l, i; FILE *toA, *fromA;
toA = fopen("/home/mechvel/ghc/notes/npipe/toA", "r");
if (toA == NULL) {perror("fopen(toA, r) failed: "); return;};
fromA = fopen("/home/mechvel/ghc/notes/npipe/fromA", "w");
if (fromA == NULL) {perror("fopen(fromA, w) failed: "); return;};
if (fgets(str, BOUND, toA) == NULL) {
perror("fgets(str, bound, toA) failed: "); return;
};
printf("input = %s\n", str);
l = strlen(str) - 1;
i = 0; // convert the string to the lower case
while (i < l) {str[i] = tolower(str[i]); i++;}
printf("output = %s\n", str);
fputs(str, fromA);
fflush(fromA);
printf("output to fromA done\n");
return;
}
-
Comparison with C - C
-
If both programs are in C, then the whole loop of the string exchange
(with fifo2.c rewritten into a loop) works as needed, both for the
variants with fgets and with `read'.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
named pipes
Dear GHC team,
I am testing the IO operations of GHC with the Unix named pipes
(in ghc-7.01 under Debian Linux).
In the below example,
the pipe pair are created by > mkfifo toA
> mkfifo fromA,
`main' in Main.hs opens toAfor writing,
opens fromA for reading,
outputs "A1" to toA.
The C program fifo2 opens toAfor reading,
opens fromA for writing,
inputs a string from toA,
prints "done" to the screen
(fromA is not really used, but will be needed in future).
The effect is that fifo2(on terminal-2) hangs silent, while
Main.hs (on terminal-1) does its part.
If I remove the fopen(..fromA..)
call in fifo2.c, then it runs as expected
(after this example is fixed, fifo2 will need to write to fromA).
Main.hs is built by ghc --make Main,
The C program is built by gcc -o fifo2 fifo2.c
First, ./fifo2 is run on terminal-2,
then./Mainis run on terminal-1.
The source is quite small:
-- Main.hs -
import System.IO (IOMode(..), IO(..), Handle, openFile, hPutStr,
hFlush)
dir = showString "/home/mechvel/ghc/notes/npipe/"
toA_IO = openFile (dir "toA") WriteMode :: IO Handle
fromA_IO = openFile (dir "fromA") ReadMode
axiomIO :: Handle -> String -> IO()
axiomIO h str = do
hPutStr h str
hFlush h
putStr "hFlush done\n"
main = do
h <- toA_IO
putStr "str1 --> "
axiomIO h "A1\n"
--- fifo2.c -
#include
#include
#define BOUND 64
static char str[BOUND];
main()
{
int l, i; FILE *toA, *fromA;
toA = fopen("/home/mechvel/ghc/notes/npipe/toA", "r");
if (toA == NULL) {perror("fopen(toA, r) failed: "); return;};
fromA = fopen("/home/mechvel/ghc/notes/npipe/fromA", "w"); // !
if (fgets(str, BOUND, toA) == NULL) {
perror("fgets(str, bound, toA) failed: "); return;
};
printf("input = %s\n", str);
printf("done\n");
return;
}
-
Can you, please, explain the effect?
Regards,
--
Sergei
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] named pipe interface
On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote: > Quoth "Serge D. Mechveliani" , > ... > > Initially, I did the example by the Foreign Function Interface for C. > > But then, I thought "But this is unnatural! Use plainly the standard > > Haskell IO, it has everything". > > > > So, your advice is "return to FFI" ? > > Well, it turns out that the I/O system functions in System.Posix.IO > may work for your purposes. I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. > > Specifically, >openFile "toA" WriteOnly Nothing defaultFileFlags >openFile "fromA" ReadOnly Nothing defaultFileFlags > >fdWrite toA str >(str, len) <- fdRead fromA 64 >return str Great! Thank you very much. As I find, Posix.IO is not of the standard, but it is of GHC. Anyway, it fits my purpose. By openFile you, probably, mean openFd. Another point is the number of open files, for a long loop. I put toA_IO = openFd "toA" WriteOnly Nothing defaultFileFlags fromA_IO = openFd "fromA" ReadOnly Nothing defaultFileFlags axiomIO :: String -> IO String axiomIO str = do toA <- toA_IO fromA <- fromA_IO fdWrite toA str (str, _len) <- fdRead fromA 64 return str When applying axiomIO in a loop of 9000 strings, it breaks: "too many open files". I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO axiomIO :: String -> IO String axiomIO str = do fdWrite toA str (str, _len) <- fdRead fromA 64 return str And now, it works in loong loops too (I need to understand further whether my usage of unsafePerformIO really damages the project). Its performance is 9/10 of the C <-> C performance (ghc -O, gcc -O, Linux Debian). It is still slow: 12 small strings/second on a 2 GHz machine. But this is something to start with. > I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. Indeed. Initially, I tried C <-> C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). Then, I tried read/write, as it is in fifoFromA.c which I posted. And it works. Now, Haskell <-> C gives a hope. Nice. Thanks, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] named pipe interface
On Fri, Jan 13, 2012 at 04:34:37PM +0100, Chadda?? Fouch?? wrote: > On Thu, Jan 12, 2012 at 7:53 PM, Serge D. Mechveliani > wrote: > > [..] > > I need to organize a string interface for a Haskell function > > Main.axiom and a C program > > fifoFromA.c > > > > via a pair of named pipes (in Linux, UNIX). > > The pipes are created before running, by the commands > mkfifo toA > > > mkfifo fromA > > > > Main.axiom outputs a string to toA and inputs the respond string > > from fromA as the result. > > fifoFromA inputs a string from toA, > > converts it to the string resStr, outputs resStr to fromA. > > > Now that seems interesting, but just to be clear : did you choose > this solution (and why won't you use the FFI instead) or is this just > to see how to work it out ? I am trying to interface my large DoCon program for algebra to (a much larger algebra program) Axiom (the FriCAS license allows this). And for many reasons, there is no real way for this except the string interface. Further, the first candidate for the string interface is Unix named pipes. If the GHC IO cannot sufficiently work with named pipes, I would return to the attempt with the Foreign Function Interface and C <-> C exchange. Sergei. mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
kinds for `*'
People, GHC provides some extensions for kinds. Does this make possible different kinds, for example, for `*' ? Prelude.Num has * :: a -> a -> a. And mathematicians also like to denote as `*' (\cdot in TeX) a "multiplication of a vector v by a coefficient r". It is expressed by the declaration class (Num r, ...) => LeftModule r v where * :: r -> v -> v Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 7.4.1-candidate
Dear GHC team, I have tested ghc-7.4.0.20111219 on Debian Linux by 1) making it from source, 2) making it by itself, 3) making DoCon-2.12 and running its test. It looks all right. In installing DoCon, there appears a new point of installing the package Random, because Random has separated from GHC. So, I write in the DoCon-2.12 announce: ** Used extra libraries (beyond Haskell-2010) Set.Set, Map.Map-- of GHC, System.Random version 1.0.1.1 -- a separate from GHC library (written in Haskell) residing on http://hackage.haskell.org/package/random (first, install GHC, then use ghc to install Random). ** Thanks to people who helped me with installing Random. I have downloaded System.Random-1.0.1.1 from http://hackage.haskell.org/package/random, unzipped it to a separate from ghc place -- call it $R, and installed it to a $R/inst by ghc --make Setup ./Setup configure --prefix=$R/inst -p ./Setup build -v ./Setup haddock ./Setup install -v After this, ghc-pkg list shows random-1.0.1.1 in the list, and now DoCon finds it. Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cabal-Random
On Sun, Jan 01, 2012 at 07:51:39AM -0500, Ryan Newton wrote: > I haven't entirely followed this and I see that it's been split over > multiple threads. > > Did "cabal install random" actually fail for you under > ghc-7.4.0.20111219? If so I'd love to know about it as the maintainer > of the "random" package. (It seems to work for me for > random-1.0.1.1.) "cabal install random" cannot run in my situation, because I have not cabal usable in the command line (I only have the Cabal library in the place where the ghc-7.4.0.20111219 libraries are installed). My idea is that having installed GHC, I use the GHC packages and, probably, do not need to install Cabal (why complicate things?, why force a DoCon user to install extra software?). > That said, I'm sure AC-random is a fine alternative, and there are > many other packages on Hackage as well, including cryptographic > strength ones (crypto-api, intel-aes, etc). I tried AC-Random, and see that it suggests just different classes, with different operations. So that all the Random instances in my application must be re-programmed. So is the consequence of being out of Standard, and out of GHC ! -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-cabal-Random
People, I have ghc-7.4.0.20111219 made from source and tested it on the DoCon-2.12 application -- thanks to people for their help! It looks all right. This was -- with skipping the module Random. Now it remains to add the Random package. I have taken AC-Random Version 0.1 from hackage. Its installation requires Cabal: > which cabal cabal: Command not found. > And Cabal is difficult to install, it reports that such and such package versions are missing. On the other hand, Cabal is, probably, present inside ghc-7.4.0.20111219, somewhere in the installation directory. Thus I see its .a and .o files in ~/ghc/7.4.1pre/inst0/lib/ghc-7.4.0.20111219/Cabal-1.14.0/ Can you, please, tell me what is the simplest way to install Random in this situation? Thank you in advance for your explanation, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.4.1-cand for docon
Dear GHC team, The archive http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc741candQuest.zip contains the source of the docon-2.12 application. ghc-7.0.1 compiles it and runs the test successfully. ghc-7.4.0.20111219 cannot compile it. 1. It requires to add Show a to Integral a in a certain place. It occurs that this requirement breaks the standard (?). But all right, so far, add Show a there and see what happens further. 2. It reports that certain two packages overlap at some module. This is a matter of the `build-depends' field in docon.cabal and of the import declarations. I tried to correct the build-depends list. But each time the compiler reports that a) some packages overlapor b) build-depends has a wrong line or c) it cannot find some module (for example, Random). Can you please, look into ghc741candQuest.zip and set there an appropriate build-depends ? (so thatmake configure make build make install finish correctly). How does the user guess of this list, what is the method? This also touches the question of the module Random - Thorkil Naur wrote > System.Random can be found in http://hackage.haskell.org/package/random. I do not find the Random class in Haskell-2010. Probably, DoCon imports Random from the GHC (non-standard) library. When installing ghc-7.01, I just download the source distribution, `make' it, and it installs automatically together with the module Random. Has the status of the module Random changed in ghc-7.4.1 ? What is a regular way to install ghc-7.4.1 together with the module Random ? 3. After the point (2) is fixed, there may appear some more of them ... Thank you in advance for your explanation, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Show and Integral
Sorry, I have forgotten to copy to the List my last note on this subject. The on-line spec of Haskell-2010 shows Eq Show \ / Num | Real | Integral Hence, for x :: Integral a => a, it is correct to apply (show x). And ghc-7.4.0.20111219 does not allow this (show x). So, it breaks the standard, and people say, this is deliberate. I witness such a break for the first time, and this looks so strange! Well, I also diskile the edge Show / Num in the standard. But it is better to implement Show as dummy for appropriate types, -- so far, -- and to wait for the next standard. Am I missing something? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build-depends
On Thu, Dec 22, 2011 at 09:48:06AM -0800, J. Garrett Morris wrote: > On Thu, Dec 22, 2011 at 9:44 AM, Serge D. Mechveliani > wrote: > > And ghc-7.4.0.20111219 reports > > DExport.hs:28:8: > > Could not find module `Random' > > It is a member of the hidden package `haskell98-2.0.0.1'. > > Perhaps you need to add `haskell98' to the build-depends in your .cabal > > file. > > Perhaps import System.Random instead? Same module, as far as I know, > but that gets it from its "real" package. > This leads to DExport.hs:28:8: Could not find module `System.Random' ? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
build-depends
Dear GHC team, ghc-7.4.0.20111219 puts the following problem of build-depends. docon.cabal of the DoCon project has build-depends: haskell2010, containers And ghc-7.4.0.20111219 reports DExport.hs:28:8: Could not find module `Random' It is a member of the hidden package `haskell98-2.0.0.1'. Perhaps you need to add `haskell98' to the build-depends in your .cabal file. Then, build-depends: haskell2010, haskell98, containers causes "Parse of field 'build-depends' failed". Then, build-depends: haskell98, containers causes VecMatr.hs:49:8: Could not find module `Data.List' It is a member of the hidden package `base'. Perhaps you need to add `base' to the build-depends in your .cabal file. It is a member of the hidden package `haskell2010-1.1.0.1'. Perhaps you need to add `haskell2010' to the build-depends in your .cabal file. Adding haskell2010 will cause "Parse of field 'build-depends' failed." Adding base will cause DExport.hs:26:8: Ambiguous module name `Prelude': it was found in multiple packages: base haskell98-2.0.0.1 Please, what is a reasonable way out ? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Prelude in 7.4.0.20111219
Dear GHC developers,
This is on ghc-7.4.0.20111219.
Compiling
---
{-# OPTIONS -fno-warn-duplicate-exports #-}
module DExport
(module DPrelude,module Categs, module SetGroup,
module RingModule, module Z, module DPair,
module Fraction,module Permut, module VecMatr,
module Pol, module Residue,module LinAlg,
module GBasis, module Partition, module AlgSymmF,
module Complex,
module Prelude, module List, module Ratio, module Random
)
where
import Complex
import Listhiding (minimum, maximum, sort, sortBy)
import Prelude hiding (minimum, maximum, )
import Ratio
...
---
ghc-7.4.0.20111219 reports (unlike ghc-7.0.1):
--
runghc Setup.hs build
Building docon-2.12...
Preprocessing library docon-2.12...
DExport.hs:26:8:
Ambiguous module name `Prelude':
it was found in multiple packages: base haskell98-2.0.0.1
--
Please, what is the best way out?
Regards,
--
Sergei
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.4.1-pre: Show & Integral
пDear GHC team, ghc-7.0.1 assumes that Integral includes Show, and ghc-7.4.0.20111219 does not assume this. Which one agrees with Haskell-2010 ? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
IO in the middle
People, is it possible to arrange a connected output and input (with something like a socket) "in a middle" of the Haskell function? Consider the example of sorting an integer list: sortInt :: [Int] -> [Int] sortInt js = let callString = "sortForeign( " ++ (show js) ++ ")" ? = outputToSocket callStr socket?-- strict order? resStr = inputFromSocket socket? :: String-- (res, _) = reads str' :: ([Int], String) in res It forms the call string for a foreign function, passes it to a Socket, the foreign system parses callString, evaluates it, and returns the string resStr for the result (inputFromSocket needs to happen later than outputToSocket). Then, reads converts it back to [Int]. Forgetting of the pure-functionality philosophy, which items in the Haskell library or in the GHC library may help? Is the C interface needed? What if there is a file instead of socket? (for this Foreign is able to apply readFile, to parse and evaluate the call). I had an experience with readFile in Haskell, but this was only the top function. Here the situation looks more complex. Thank you in advance for your explanation. -- Sergei. mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance union decl
The general idea of my recent instance union proposal is that for a single polymorphic type T, sometimes it is natural to define several instances by a single `instances' declaration. -- Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
instance union proposal
Dear Haskell implementors,
I suggest the following small extension to the instance declaration in
the language. So far -- for Haskell + glasgow-ext.
I think that they are easy to implement.
This is the "instance union" proposal.
It is needed to write shorter several `old' instance declarations.
This will make programs easier to read.
It suggests the so-called
inherited decl and, more general, union decl.
Inherited instance decl proposal
Union several instance declarations with the same condition part and such
that among the conclusion classes there exists some which inherits all
others.
Example 1. My program uses the class tower
Field a Picture 1.
|
ERing
|
CRing a
|
Ring a
/\
AddGroup a MulSemigroup a
| |
AddSemigroup a |
\ /
Set a
-- "|" means that the upper inherits from the lower.
Now, by the application meaning, I need to write
instance (Show a, CRing a) => CRing (Pol a)
where
...
>From the class decls it is clear to the compiler that CRing inherits
all that is lower on the picture. Therefore, the conditional
`instance (Show a, CRing a) =>' and 'where'
is written only once.
In the existing language, I need to write this conditional 6 times.
Union instance decl proposal
It is a generalization for inhereted decl.
instances (cond_1, ..., cond_n) -- of the type parameters a_1 ... a_m
=>
() has {}
where
.
It differs from the old instance declaration in that
1) it unions several old declarations having the same conditional part,
2) each member of can be conditional,
3) in it can be skipped any instance which is inherited
by some other member in this list.
is a subset of {a_1 ... a_m},
()
is a tuple of type expressions, as in old declaration,
for example, `(a, b)', `Vector a', `[(a,b), Vector a]'.
It is the argument for the conclusion instance declarations.
is a list of inst-members separated by comma.
Each member ofis either an
old conclusion instance declaration
or a conditional declaration.
Example.
In the situtation of Picture 1, I need to declare
instance (Show a, CRing a) =>
(Pol a) has { CRing, if (has a Field) then ERing }
where
...
-- this part has the
-- additional condition (Field a)
Its meaning is that the complier extends this into several `old'
instance declarations:
instance (Show a, CRing a) => Set (Pol a) where
...
instance (Show a, CRing a) => CRing (Pol a) where
instance (Show a, Field a) => ERing (Pol a) where
(in the last decl `Field a' has been moved to LHS).
In this example === (Pol a).
For bi-parametric instances, the concusion part may be, for example
=>
[a, Pol a] has {Foo1, Foo2} ...
This means the two instance assertions Foo1 a (Pol a), Foo a (Pol a),
and `[a, Pol a]' is the agrument tuple for the instance conclusions.
This is a draft proposal. If the idea is accepted, some generalizations
and corrections are expected.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
C, GCL interface
Dear GHC developers, There is a computer algebra library called DoCon and written in Haskell (+GHC). And I am considering the possibility to extend it with many new methods by joining some open libraries written in C, C++, and in Gnu Common Lisp (GCL). 1. I have seen somewhere the announcement of the C library for numbers, algebraic numbers by Lenstra and may be, others. Is it real to design its interface to a Haskell program (DoCon), may be, by using some tools from GHC ? (which tools?) 2. There exists a great volum of math libraries written in Lisp-s, in particular, in GCL. I believe some of them have a free enough license. But how to interface to them? For example, is there possible an interpreter for GCL written in C ? If it is, then, may be, the GCL libraries can be interfaced by joining and applying this interpreter at the C data level? Also I have looked in the GCL page, and it was not clear where to ask about such GCL interpreter. I never tried these interface tricks and never looked into the Lisp design. Thank you in advance for your advice. - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #5051: Typechecker behaviour change
Simon, thank you. Currently, DoCon works under ghc-7.0.1. And as I understand, the next release which is going to support DoCon (with its heavy use of overlapping instances) will be ghc-7.2. Regards, Serge Mechveliani, mech...@botik.ru On Wed, Jun 22, 2011 at 11:01:53AM -, GHC wrote: > #5051: Typechecker behaviour change > ---+ > Reporter: igloo | Owner: simonpj > Type: bug | Status: closed > Priority: high | Milestone: 7.2.1 > Component: Compiler |Version: 7.0.2 > Resolution: fixed | Keywords: > > [..] > > GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather > subtle interaction of overlapping instances with the ill-fated "silent > superclass parameters" I introduced to solve a problem in the > typechecker's constraint solver. > [..] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 7.02-candidate
This is to add to my last letter. It is curious that this 7.02 candidate stucks at оverlapping instances only when compiling the test: T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' ... In earlier versions, if any of them stuck at оverlapping instances, the report was earlier, when compiling the DoCon library. --- Mechveliani ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 7.02-candidate
Dear GHC team, I am testing the 7.02 candidate of ghc-7.0.1.20110217 -- compiled from source, compiled by itself, on Debian Linux, i386-family. On my DoCon program, it reports the following. 1. It requires `-fcontext-stack=_' to increase a certain stack: ... [67 of 83] Compiling Pfact__( Pfact__.hs, dist/build/Pfact__.o ) [68 of 83] Compiling RsePol_( RsePol_.hs, dist/build/RsePol_.o ) RsePol_.hs:214:28: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSet :: Set (UPol (ResidueE Integer)) $dAddSemigroup :: AddSemigroup (UPol (ResidueE Integer)) $dAddMonoid :: AddMonoid (UPol (ResidueE Integer)) ... $dCast :: Prelude_.Cast (ResidueE (UPol (Pfact__.RseUPolRse Integer))) (UPol (Pfact__.RseUPolRse Integer)) In the first argument of `(.)', namely `ct c1' In the expression: ct c1 . toOverK . resRepr In an equation for `toC': toC = ct c1 . toOverK . resRepr --- So, I add -fcontext-stack=30 to the ghc-options line in docon.cabal. Which one is better at this point, 7.0.1 or 7.0.1.20110217 ? 2. Then, DoCon is built, and the commands cd demotest ghc $doconCpOpt -O -rtsopts --make Main need to `make' the DoCon test under the DoCon library. This reports [ 1 of 17] Compiling T_detinterp ( T_detinterp.hs, T_detinterp.o ) [ 2 of 17] Compiling T_sphGeo ( T_sphGeo.hs, T_sphGeo.o ) [ 3 of 17] Compiling T_cubeext( T_cubeext.hs, T_cubeext.o ) T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' Matching instances: instance [overlap ok] EuclideanRing a => LinSolvRing (UPol a) -- Defined in docon-2.12:Pol2_ instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) -- Defined in docon-2.12:Pol3_ (The choice depends on the instantiation of `k' To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the first argument of `(.)', namely `ct unE' In the expression: ct unE . kToB In an equation for `kToE': kToE = ct unE . kToB This looks like a bug of the kind appeared in a couple of earlier GHC versions. ghc-7.0.1 is free of both of these effects. What is your opinion about this? http://www.botik.ru/pub/local/Mechveliani/ghcBugs/702candBug.zip is the archive with the project to make and run under ghc-7.0.1, and ghc-7.0.1.20110217 (follow install.txt). Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
lib for tuples
People, I define, for example, tuple42(_, y, _, _) = y, setTuple42 (x, _, z, u) y = (x, y, z, u), mapTuple42 f (x, y, z, u) = (x, f y, z, u). But it looks natural to have such functions for tuples in the library. As Haskell-2010 has zip3, zip4 ..., where are the library functions tupleij, setTupleij, mapTupleij, say, for i, j <- [2 .. 6] ? I expected to find in the Report "Data.Tuple" similar as "Data.List", but do not. GHC has "Data.Tuple", but it misses the above functions. Thank you in advance for your comments, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
List vs Data.List
In ghc-7.0.1, to import `partition', it is sufficient the line import List (partition), but to import `intercalate', it is needed import Data.List (intercalate). Does Haskell-2010 differ between List and Data.List import? Thank you in advance for explanation, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Require OverlappingInstances for the most specific instance only
If it does not effect working programs, than I vote for hackage.haskell.org/trac/ghc/ticket/3877 -- to apply this change for OverlappingInstances. If it does effect, than I would like to have a special pre-release for testing and feeding back from users. > [..] define further places where you say that you want an overlapping > instance. I compile all my (two) projects under MultiParamTypeClasses OverlappingInstances UndecidableInstances FlexibleInstances FlexibleContexts -- I put this to the line of `extensions' in the *.cabal file. And this correlates in a certain way with the way in which GHC complies the library instances. Also I could try to set/skip OverlappingInstances to each module individually -- do not know, so far, whether I really need this. - Serge Mechveliani mech...@botik.ru On Tue, Nov 16, 2010 at 05:02:09PM +0100, Christian H?ner zu Siederdissen wrote: > The change should not affect working programs, as it just allows you to > define further places where you say that you want an overlapping > instance. > > Gruss, > Christian > > * Serge D. Mechveliani [16.11.2010 16:47]: > > On Tue, Oct 26, 2010 at 09:41:58PM +0200, John Smith wrote: > > > In the case of overlapping instance declarations, GHC currently requires > > > the less specific instance to be compiled with OverlappingInstances for > > > the > > > more specific instance to be usable. This means that, for example, if you > > > write > > > > > > type ChessBoard = Array (Int,Int) Piece > > > > > > there is no way to > > > > > > instance Show ChessBoard where > > > show board = ... > > > > > > because Array is already an instance of Show, and was not compiled with > > > OverlappingInstances. > > > > > > http://hackage.haskell.org/trac/ghc/ticket/3877 requests that > > > OverlappingInstances be required for only the most specific instance > > > declarations, as suggested in the documentation. "Perhaps the rule should > > > instead say that the overlapping instance declaration should be compiled > > > in > > > this way, rather than the overlapped one ... We are interested to receive > > > feedback on these points." > > > > > > SPJ offered to make this change, if the list users agree. (See comment > > > 6.) > > > Proposed deadline for discussion is 16th November. > > > > > > > > I always expected that such programs as above must be valid. > > On the other hand, I do not understand these possible ways of compilation, > > these words about "compiled in this way, rather than the overlapped one". > > Now, as I already have overlapping instances work in my programs, for a > > long time, it is difficult for me to predict the consequences of the > > change. > > Can the team issue the corresponding GHC pre-release for testing, > > without making a decision for future before the users report their > > impression? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Require OverlappingInstances for the most specific instance only
On Tue, Oct 26, 2010 at 09:41:58PM +0200, John Smith wrote: > In the case of overlapping instance declarations, GHC currently requires > the less specific instance to be compiled with OverlappingInstances for the > more specific instance to be usable. This means that, for example, if you > write > > type ChessBoard = Array (Int,Int) Piece > > there is no way to > > instance Show ChessBoard where > show board = ... > > because Array is already an instance of Show, and was not compiled with > OverlappingInstances. > > http://hackage.haskell.org/trac/ghc/ticket/3877 requests that > OverlappingInstances be required for only the most specific instance > declarations, as suggested in the documentation. "Perhaps the rule should > instead say that the overlapping instance declaration should be compiled in > this way, rather than the overlapped one ... We are interested to receive > feedback on these points." > > SPJ offered to make this change, if the list users agree. (See comment 6.) > Proposed deadline for discussion is 16th November. I always expected that such programs as above must be valid. On the other hand, I do not understand these possible ways of compilation, these words about "compiled in this way, rather than the overlapped one". Now, as I already have overlapping instances work in my programs, for a long time, it is difficult for me to predict the consequences of the change. Can the team issue the corresponding GHC pre-release for testing, without making a decision for future before the users report their impression? With kind regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
making 7.01-pre
Dear GHC developers, I am testing this fresh ghc-7.0.0.20101028 on Debian Linux, i386-family. Making it from source by ghc-6.12.3 is all right. Then, making it from source by itself reports (here I abbreviate the messages by inserting `...') - + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old ... ... "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "/home/mechvel/ghc/7.01pre/inst1/bin/ghc" -H32m -O --make utils/ghc-cabal/ghc-cabal.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ... "rm" -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. "/usr/bin/gcc" -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' ... ... utils/genprimopcode/dist/build/Parser.o: In function `s4pK_info': (.text+0x5691): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' collect2: ld returned 1 exit status make[1]: *** [utils/genprimopcode/dist/build/tmp/genprimopcode] Error 1 make: *** [all] Error 2 - Why cannot it make itself? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
new-www
People, what is, in short, the relation between www.haskell.org and new-www.haskell.org ? Which one do I need to use for looking for the Haskell materials, for GHC materials? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unused record fields
Simon P. Jones wrote recently about that ghc-6.12 takes in
account the elliplis in MkT {t1 = x, ..} when reporting about
unused bindings.
Now, here is the example:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
And forf (T {t1 = x, ..}) = x,
it does not warn about this.
Is this a bug?
I use
extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns
ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-O0
,
but the options can be simplified, of course.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: un-used record wildcards
Thank you.
This was with ghc-6.12.2 and
RecordWildCards
TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances,
-fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports
-fno-warn-overlapping-patterns
1) Then, I dropped `,..' in the places where I do not really need other
fields, and it has improved.
2) Now, after reading your letter, I tried your example with MkT, and
it is all right. Then, I returned `,..' to my code (still the precise
initial code is lost, too many changes done), and I cannot obtain now
these messages about unused binds.
Most probably, this was some other effect with the variables.
The program is complex, and I have lost the initial code due to
`successfull' attempt with omitting elliplis. I also have to see how the
result program will work, this is my first attempt with RecordWildCards,
and now, also with NamedFieldPuns.
---
Mechveliani
On Thu, Oct 14, 2010 at 10:06:49PM +, Simon Peyton-Jones wrote:
> Which version of GHC are you using? GHC 6.12 does not complain about unused
> variables bound by "..". Try this, which complains about y, but not g.
>
> Simon
>
> {-# LANGUAGE RecordWildCards #-}
> module Test where
>
> data T = MkT { f,g :: Int }
>
> p (MkT { .. }) y = f
>
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Serge D. Mechveliani
> | Sent: 14 October 2010 11:01
> | To: Antoine Latter
> | Cc: glasgow-haskell-users@haskell.org
> | Subject: Re: un-used record wildcards
> |
> | On Wed, Oct 13, 2010 at 01:47:11PM -0500, Antoine Latter wrote:
> | > On Wed, Oct 13, 2010 at 1:02 PM, Serge D. Mechveliani
> | wrote:
> | > > Dear GHC developers,
> | > >
> | > > I use the language extension of RecordWildcards, for example,
> | > > f (Foo {foo1 = n, foo2 = m, ..}) = ...
> | > >
> | > > But the complier warns about un-used values of foo3, foo4,
> | > > probably, due to the extension of
> | > > Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}.
> | > >
> | > > In such cases, these warnings look as unneeded.
> | > > Is it possible to have an un-used binding warnings with exception for
> | > > wildcards in records?
> | > > If not, then has it sense to introduce an option?
> | > >
> | >
> | > If you're not using foo3 and foo4, can you not put it the ellipsis?
> | > that won't cover every case (such as where you're using foo3 but not
> | > foo4).
> | >
> | > Antoine
> | >
> |
> | Indeed, thank you.
> | It occurs that under RecordWildcards the compiler allows to skip some
> | record fields in a pattern.
> | ___
> | 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: Set inclusion
On Thu, Oct 14, 2010 at 05:27:52PM +0200, Christian Maeder wrote: > Am 14.10.2010 15:44, schrieb Serge D. Mechveliani: > > I have the two notes on the GHC library. > > The docs show that > > 1. Map has the function for the Map inclusion relation, > >and Set does not have such for sets. > > Which function(s) do you mean? > > Data.Map: > isSubmapOf :: (Ord k, Eq a) => Map k a -> Map k a -> Bool > [..] > isSubsetOf :: Ord a => Set a -> Set a -> Bool > isProperSubsetOf :: Ord a => Set a -> Set a -> Bool > I am sorry for missing this. Now I see that GHC is all right at this point. - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Set inclusion
I have the two notes on the GHC library. The docs show that 1. Map has the function for the Map inclusion relation, and Set does not have such for sets. 2. notMember looks unnecessary, because one can write not . Map.member k. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: un-used record wildcards
On Wed, Oct 13, 2010 at 01:47:11PM -0500, Antoine Latter wrote:
> On Wed, Oct 13, 2010 at 1:02 PM, Serge D. Mechveliani
> wrote:
> > Dear GHC developers,
> >
> > I use the language extension of RecordWildcards, for example,
> > f (Foo {foo1 = n, foo2 = m, ..}) = ...
> >
> > But the complier warns about un-used values of foo3, foo4,
> > probably, due to the extension of
> > Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}.
> >
> > In such cases, these warnings look as unneeded.
> > Is it possible to have an un-used binding warnings with exception for
> > wildcards in records?
> > If not, then has it sense to introduce an option?
> >
>
> If you're not using foo3 and foo4, can you not put it the ellipsis?
> that won't cover every case (such as where you're using foo3 but not
> foo4).
>
> Antoine
>
Indeed, thank you.
It occurs that under RecordWildcards the compiler allows to skip some
record fields in a pattern.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
un-used record wildcards
Dear GHC developers,
I use the language extension of RecordWildcards, for example,
f (Foo {foo1 = n, foo2 = m, ..}) = ...
But the complier warns about un-used values of foo3, foo4,
probably, due to the extension of
Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}.
In such cases, these warnings look as unneeded.
Is it possible to have an un-used binding warnings with exception for
wildcards in records?
If not, then has it sense to introduce an option?
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
report on 7.01-pre
Dear GHC developers, http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip contains a bug report on ghc-7.0.0.20100924 tested on Debian Linux, i386-family. Its essence is as follows. At the fragment of - instance (LinSolvRing (Pol a), CommutativeRing a) => -- (1) LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP= f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... - in the module Pol3_.hs, ghc-7.0.0.20100924 reports that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. ghc-6.12.2 compiles this in a correct way: (EuclideanRing a) is not necessary here, while the context (1) is more generic and sufficient. For example, for a = DirectSum Integer Integer, `a' has the instances (1) and has not the instance of Euclidean, and the above code must work. This is the idea of the author of the application; this idea is supported by ghc-6.12.2 and not supported by ghc-7.0.0.20100924. There are the two questions. 1) Whether this intention with instances is correct in the meaning of Haskell + ghcExt (I hope, it is correct, at least, ghc-6.12.2 accepts it). 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? Notices --- a) This application uses multiparametric classes and overlapping instances (see docon.cabal for language and other options). b) The example code can be reduced further, many times. But I may have time to reduce it maybe only in the middle of December 2010. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 7.01-pre
On Thu, Sep 30, 2010 at 02:13:49AM +, Simon Peyton-Jones wrote: > | (2) ghc-6.12.2 compiles docon-2.11 > | (download it via http://haskell.org/ghc/docon/ > | and follow install.txt > | ) > > I get "Not found" when following http://haskell.org/ghc/docon > > Simon > Sorry, it is http://haskell.org/docon/distrib Also I rewise my last notice about instance (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) and pretend now that it is a bug report on ghc-7.0.0.20100924. I am going now to provide a report. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 7.01-pre
Dear GHC developers, I have tested ghc-7.0.0.20100924 on Debian Linux, i386-family on making it by ghc-6.12.3, on the DoCon test, -- with skipping profiling. There are visible the following changes in GHC: (1) Usage of ./Main +RTS .. -RTS needs linking with -rtsopts (2) ghc-6.12.2 compiles docon-2.11 (download it via http://haskell.org/ghc/docon/ and follow install.txt ) and ghc-7.0.0.20100924 cannot. It declares ... DPair.hs:316:35: Couldn't match type `b' with `a' `b' is a rigid type variable bound by the instance declaration at DPair.hs:222:38 `a' is a rigid type variable bound by the instance declaration at DPair.hs:222:23 In the first argument of `restore', namely `zrB' In the expression: restore zrB bs qB' In an equation for `qB': qB = restore zrB bs qB' (3) I also tried docon-2.12 (which differs very slightly from docon-2.11 and which I can provide if asked). ghc-6.12.3 makes it and runs the test successfully. Compiling it by ghc-7.0.0.20100924 stops (close to end) at Pol3_.hs at the fragment of - instance (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP= f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... It declares that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. I think, for the need of this particular application it is indeed better to change the context to `EuclideanRing a =>' (probably, the initial complicated context was forced by old GHC). After changing it to `EuclideanRing a =>', ghc-7.0.0.20100924 makes docon-2.12 and runs the test successfully. You see, the points (2) and (3) present a certain question about the compler. I wonder wich complier is more correct. (Recall also that Docon uses an extension with overlapping instances, multiparametric classes, and such). (4) At the docon-2.12 test made under -O, ghc-7.0.0.20100924 shows the time 3.9 sec instead of 3.3 sec of ghc-6.12.3. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
laziness in `length'
Dear people and GHC team, I have a naive question about the compiler and library of ghc-6.12.3. Consider the program import List (genericLength) main = putStr $ shows (genericLength [1 .. n]) "\n" where n = -- 10^6, 10^7, 10^8 ... (1) When it is compiled under -O, it runs in a small constant space in n and in a time approximately proportional to n. (2) When it is compiled without -O, it takes at the run-time the stack proportional to n, and it takes enormousely large time for n >= 10^7. (3) In the interpreter mode ghci, `genericLength [1 .. n]' takes as much resource as (2). Are the points (2) and (3) natural for an Haskell implementation? Independently on whether lng is inlined or not, its lazy evaluation is, probably, like this: lng [1 .. n] = lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) = 1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = 2 + (lng (3: (list 4 n))) -- because this "+" is of Integer = 2 + 1 + (lng $ list 4 n) = 3 + (lng $ list 4 n) ... And this takes a small constant space. Thank you in advance for your explanation, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.12.3-candidate
Dear GHC developers, I have tested ghc-6.12.3-candidate of 6.12.2.20100521 on Debian Linux, i386-family on making it by ghc-6.12.2, on making it by itself on the DoCon test,on the Dumatel test -- with skipping profiling. It looks all right. - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -K in 6.12.2
I am sorry, please withdraw my last letter (about -M, -K): > For the test compiled under -O, 2300k in "./Main +RTS -K2300k -RTS" > is the minimal memory option of this kind for the test to finish without > break. > [..] I have confused "-M...k" with "-K...k". Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-K in 6.12.2
Dear GHC developers, I am trying ghc-6.12.2 on Debian Linux, i386-family, on the DoCon test. There is a difference in memory management, with respect to 6.12.1. For the test compiled under -O, 2300k in "./Main +RTS -K2300k -RTS" is the minimal memory option of this kind for the test to finish without break. In 6.12.2, 90k is sufficient, maybe, GHC ignores this "-K", -"M" ... Could you explain, please? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 6.12.2-pre
Dear GHC developers, I have tested ghc-6.12.1.20100330 on Debian Linux, i386-family, on the DoCon test, without profilig. It looks all right. - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
keyword in pragma
In my last letter I wrote about the prossibility for the GHC developers to require a keyword in any pragma, "for future". I thought that pragma is a matter of the GHC language extension. But if it is of the Haskell standard, then, again I am sorry! Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forgetting SCC
On Sun, Feb 07, 2010 at 02:16:11PM +0100, Daniel Fischer wrote:
> Am Sonntag 07 Februar 2010 14:05:48 schrieb Serge D. Mechveliani:
> > On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote:
> > > Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani:
> > > > I am sorry,
> > > > indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo"
> > > > #-}. I have just missed this warning.
> > > >
> > > > The next question is: why it is a warning and not an error break?
> > >
> > > Because it might be a valid pragma for some other implementation, so
> > > erroring on unrecognised pragmas is not a good option.
> > > [..]
> >
> > Some of earlier implementations or only future?
>
> I know of no implementation that used {-# "string" #-} as a pragma, so
> future.
>
> > Do you expect for future to appear a pragma without its keyword?
>
> No. But you can't be sure, can you?
My idea and suggestion is:
if the GHC developers take for future that each pragma must have its
keyword, then this will prevent some user errors.
And the question is: what might be the drawback, I wonder.
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forgetting SCC
On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote:
> Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani:
> > I am sorry,
> > indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo" #-}.
> > I have just missed this warning.
> >
> > The next question is: why it is a warning and not an error break?
>
> Because it might be a valid pragma for some other implementation, so
> erroring on unrecognised pragmas is not a good option.
> [..]
Some of earlier implementations or only future?
Do you expect for future to appear a pragma without its keyword?
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forgetting SCC
I am sorry,
indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo" #-}.
I have just missed this warning.
The next question is: why it is a warning and not an error break?
-
Serge Mechveliani
mech...@botik.ru
On Sun, Feb 07, 2010 at 10:56:53AM +, Ian Lynagh wrote:
> On Sun, Feb 07, 2010 at 11:39:31AM +0300, Serge D. Mechveliani wrote:
> > On Sat, Feb 06, 2010 at 08:24:07PM +, Ian Lynagh wrote:
> > > On Sun, Jan 31, 2010 at 10:09:42PM +0300, Serge D. Mechveliani wrote:
> > > > I have a suggestion:
> > > > is it better for GHC to report an error on the source of kind
> > > > {-# "foo" #-}
> > > > (entered by a typo instead of {-# SCC "foo" #-}) ?
> > > > Currently, GHC makes the program under (-prof) in which, the "foo"
> > > > center
> > > > occurs skipped. This misleads the user:
> > > > "foo is not in the profiling head, so it takes zero cost".
> > >
> > > 6.12.1 will warn:
> > >
> > > q.hs:3:0: Unrecognised pragma
> > >
> > > by default.
> >
> > May be, you mean the version next to 6.12.1 ?
> > Because this my report is exactly on 6.12.1.
>
> No, in 6.12.1:
>
> $ cat Q.hs
>
> module Q where
>
> {-# "foo" #-}
>
> $ ghci Q.hs
> GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> [1 of 1] Compiling Q( Q.hs, interpreted )
>
> Q.hs:4:0: Unrecognised pragma
> Ok, modules loaded: Q.
> *Q>
>
>
> Thanks
> Ian
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: profiling,-O in 6.12.1
To my
> > Dear GHC team,
> >
> > It looks like ghc-6.12.1 reports erroneous time profiling --
> > when the Main module of the project is made under -O.
> > [..]
> > This is for ghc-6.12.1 made from source for Debian Linux and
> > i386-like.
> >
> > Main.main calls for Complete.complete, `complete' calls for
> > eLoop inside its source.
> > eLoop must take almost all the time.
> > My whole user library is made under -O -prof, and
> > --enable-library-profiling.
> > Main is compiled by
> > ghc $dmCpOpt -prof --make Main
> > and run by ./Main +RTS -M400m -pT -RTS
> > For this key, the profiling report Main.prof looks natural and shows
> >eLoop -- 97%.
> >
> > But forghc $dmCpOpt -O -prof --make Make,
> >
> > it shows a different thing: zero for eLoop and 99% for `main'.
>
On Wed, Feb 03, 2010 at 05:38:36PM +0100, Daniel Fischer wrote:
> Could be that eLoop is inlined with -O.
Thank you.
I also thought about this. But the question still looks difficult.
> Try
>
> ghc $dmCpOpt -O -prof -auto-all --make
>
> That should show eLoop (if that's a top-level declaration, otherwise you'd
> have to insert a pragma {-# SCC "eLoop" #-} manually).
>
eLoop is not a top-level declaration, and I do set {-# SCC "eLoop" #-}.
The key combination
ghc $dmCpOpt -prof --make Main
shows 95% for eLoop,
and adding -O to this line shows 0% for eLoop, independently on
presence of -auto-all in this line
(the whole library is made under -O -prof).
Yes, I recall that the effect may be of inlining.
But, generally, how to detect sensibly the time consuming functions?
This inlining presents a puzzle here.
Is it possible to
compile Main.hs and Complete.hs under -O0 -inline-not,
compile all the other modules under -O
?
(how?).
If it is possible, will this make easier to understand the profiling
report?
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
profiling,-O in 6.12.1
Dear GHC team, It looks like ghc-6.12.1 reports erroneous time profiling -- when the Main module of the project is made under -O. This is for ghc-6.12.1 made from source for Debian Linux and i386-like. Main.main calls for Complete.complete, `complete' calls for eLoop inside its source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But forghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
forgetting SCC
I have a suggestion:
is it better for GHC to report an error on the source of kind
{-# "foo" #-}
(entered by a typo instead of {-# SCC "foo" #-}) ?
Currently, GHC makes the program under (-prof) in which, the "foo" center
occurs skipped. This misleads the user:
"foo is not in the profiling head, so it takes zero cost".
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: tracing messages
On Thu, Jan 28, 2010 at 02:39:56PM +, Simon Marlow wrote:
> On 28/01/2010 14:27, Serge D. Mechveliani wrote:
> >Dear GHC team,
> >
> >this is on tracing in ghc-6.12.1
> >(made from source on Debian Linux i-386-like machine).
> >
> >I wonder what is the reason for this tracing message
> >(starting with `Step1 ...' ):
> >
> >
> >...
> >equations calc =
> >[j< i -> true,
> >m<= p -> true,
> >p<= q -> true,
> >q<= n -> true,
> >(A p)<= (A q) -> false,
> >(X<= Y) | (Y< X) -> true,
> >| {not (Y<= n), not (m<= X), not (X< i), not (j< Y), (A X)<= (A Y)} ->
> >true,
> >| {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} -> true,
> >| {not (XStep 1. Starting mutual pre-reduction. The number of rules is
> >25.
> >Pre-reduction done. Initial numbers of equations is 9,
> >after reduction: 9, the pre-reduction cost is 484.
> >...
> >...
> >
> >
> >The main program does the following in succession:
> >1) finds eqs,
> >2) prints
> >"equations calc =\n", shows eqs "\n\n",
> >"Starting completion.\n",
> >"remaining goals = ",
> >3) finds res by completion (`complete'),
> >4) prints
> > shows (completionGoalRem res) "\n"
> >
> >The trace calls are set only in the function `complete'.
> >The above message
> > Step 1. Starting mutual pre-reduction. The number of rules is 25.
> > Pre-reduction done. Initial numbers of equations is 9,
> >
> >occurs the first message of this tracing.
> >But the main program must have printed the full last equation in
> >eqs, and only after this any tracing message could appear.
> >Instead, it breaks the last equation printing with the tracing messages.
> >The further evaluation is long, so I interrupted it, without seeing the
> >final result. But this printing break looks strange, because eqs
> >does not depend on the results of `complete', the reverse holds: the
> >latter applies to eqs.
> >Generally, I often observe an effect of this kind; it is harmless, but
> >I wonder, what might be the reason.
>
> Perhaps your program output is going to stdout, and the trace messages
> are going to stderr? Buffering would make them appear out of order.
>
> If you're using Debug.trace, I wouldn't recommend that for production
> use, only debugging.
>
> Cheers,
> Simon
Thank you.
Probably, this is the matter of stdout+stderr+bufering.
I run it by Main > & log, and then, see ./log.
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
tracing messages
Dear GHC team,
this is on tracing in ghc-6.12.1
(made from source on Debian Linux i-386-like machine).
I wonder what is the reason for this tracing message
(starting with `Step1 ...' ):
...
equations calc =
[j < i -> true,
m <= p -> true,
p <= q -> true,
q <= n -> true,
(A p) <= (A q) -> false,
(X <= Y) | (Y < X) -> true,
| {not (Y <= n), not (m <= X), not (X < i), not (j < Y), (A X) <= (A Y)} ->
true,
| {not (X <= Y), not (Y <= j), not (m <= X), (A X) <= (A Y)} -> true,
| {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
after reduction: 9, the pre-reduction cost is 484.
...
...
The main program does the following in succession:
1) finds eqs,
2) prints
"equations calc =\n", shows eqs "\n\n",
"Starting completion.\n",
"remaining goals = ",
3) finds res by completion (`complete'),
4) prints
shows (completionGoalRem res) "\n"
The trace calls are set only in the function `complete'.
The above message
Step 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
occurs the first message of this tracing.
But the main program must have printed the full last equation in
eqs, and only after this any tracing message could appear.
Instead, it breaks the last equation printing with the tracing messages.
The further evaluation is long, so I interrupted it, without seeing the
final result. But this printing break looks strange, because eqs
does not depend on the results of `complete', the reverse holds: the
latter applies to eqs.
Generally, I often observe an effect of this kind; it is harmless, but
I wonder, what might be the reason.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 6.12.1-pre
Dear GHC team, I have tested ghc-6.12.0.20091121 by 1) installing its binary and making and running the DoCon and Dumatel programs, 2) making it from source by its binary, making and running on it the DoCon and Dumatel programs. It looks all right. I skipped profiling. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bug in 6.12.1-pre
Dear GHC team, I tried ghc-6.12.0.20091010-src.tar.bz2 on Linux, Debian, i386-* And it cannot compile my Dumatel project. It fails at the segment: module Bug where compose :: [a -> a] -> a -> a compose = foldr (.) id class Compose a where compose1 :: a -> a -> a ghc -c -O Bug.hs reports /tmp/ghc29984_0/ghc29984_0.s: Assembler messages: /tmp/ghc29984_0/ghc29984_0.s:23:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc29984_0/ghc29984_0.s:102:0: Error: symbol `Bug_compose1_info' is already defined `-O' is essential here. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.1 Release Candidate 1
I have downloaded ghc-6.12.0.20091010-src.tar.bz2. But where to read the release notes? ANNOUNCE shows ``version 6.10.1'', and lists the old features. What is the difference of 6.12.1 w.r.to 6.10.4 ? Regards, - Serge Mechveliani mech...@botik.ru On Sun, Oct 11, 2009 at 09:41:53PM +0100, Ian Lynagh wrote: > > Hi all, > > We are pleased to (finally!) announce the first release candidate > for GHC 6.12.1: > > http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ > > As well as the source tarball: > ghc-6.12.0.20091010-src.tar.bz2 > there are installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. For the Linux binary > distributions, the "linux-n" tarballs are recommended over the "linux" > tarballs. > > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > ___ > 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
Functor
People, I have data DBit = Bit0 | Bit1 deriving (Eq, Ord, Enum) data BNatural = BNat [DBit] deriving (Eq) and want to apply things like fmap reverse (bn :: BNatural). GHC reports an error on this usage of fmap. It also does not allow instance Functor BNatural where fmap f (BNat ds) = BNat $ f ds, -- it reports that a type constructor for Functor must have kind * -> *. Probaly, GHC agrees with Haskell at this point (?). Now, I deceive the compiler by declaring instead newtype BNatAux a = BNat a deriving (Eq) typeBNatural = BNatAux [DBit] instance Functor BNatAux where fmap f (BNat ds) = BNat $ f ds So, a parasitic BNatAux is introduced. I wonder: is there a simpler way to have fmap for BNatural ? Thank you in advance for advice, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fromEnum (c :: Char)
People, I need to convert Char <-> Int in a possibly _standard_ way for Haskell -- and also in an efficient way. In particular, it must not spend 100 comparisons in a look through the listing of Char. I use ord :: Char -> Int and chr :: Int -> Char. Is this all right? Thank you in advance for advice, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling large source files
On Tue, Aug 04, 2009 at 09:12:37AM +0100, Simon Marlow wrote: > I suggest not using Haskell for your list. Put the data in a file and > read it at runtime, or put it in a static C array and link it in. > > On 03/08/2009 22:09, G?nther Schmidt wrote: > >Hi Thomas, > >yes, a source file with a single literal list with 85k elements. People, when a program only defines and returns a String constant of n literals, how much memory needs ghc-6.10.4 to compile it ? O(n), or may be O(n^2), or ... Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re to `optimization for list'
Joshua Haberman writes on 2 Aug 2009 > Hello, I'm quite new to Haskell, but experienced in other languages (C, > Python, Ruby, SQL, etc). I am interested in Haskell because I've heard > that the language is capable of lots of optimizations based on laziness, > and I want to learn more about that. > > I dug in with Project Euler problem #1, and wrote: > > main = > print (show (sum [x | x <- [3..999], x `mod` 3 == 0 || x `mod` 5 == 0])) > > So far so good, but I want to have some way of observing what > optimizations GHC has performed. Most notably, in this example I want > to know if the list was ever actually constructed in memory. The "sum" > function only needs the elements one at a time, in order, so if Haskell > and GHC are everything I've heard about them, I would fully expect the > list construction to be optimized out. :) > [..] Your example is rather complex to start with, because `sum' has rather a complex definition in the Haskell library. Consider first a more pure example: main = putStr (shows (or' ys) "\n") where n = 10^8 ys = replicate n False or' :: [Bool] -> Bool or' [] = False or' (x: xs) = x || (or' xs) (the functions `||' (disjunction) and `replicate' are of the library). Compile it with ghc --make -O (for any occasion), and then, it will be evident that it takes a constant in n space (and stack) when running (run it like this: `./T +RTS -M1m -RTS' ). I think, this is not due to optimization but due to the very definition of evaluation in Haskell -- Head Normal Form. Compute this by hand: or' (replicate 9 False) = or' (False: (replicate 8 False)) = False || (or' (replicate 8 False)) = or' (replicate 8 False) = -- by definition of || ... or' [] = False. This is just the definition of evaluation in the Haskell language. In this example, the list under or' never expands further than for 2 members. Consider a more complex example (and more close to your example): main = putStr (shows (sum2 ys) "\n") -- sum' where n = 10^7 ys = [1 .. n] sum2 :: [Int] -> Int sum2 xs = sm xs 0 where sm [] s = s sm (x: xs) s = sm xs (s+x) sum' :: [Int] -> Int sum' [] = 0 sum' (x: xs) = x + (sum' xs) (the function [n .. m] is of the library). Compile it with ghc --make -O, and then, it will be evident that sum2 takes a constant in n space (and stack) when running (run it like this: `./T +RTS -M1m -RTS' ). Let us investigate this. Furst, compute this by hand with treating (+) as not of the library: sm [1 .. 4] 0 = sm (1:[2 .. 4]) 0 = sm [2 .. 4] (1+0) = sm (2: [3 .. 4]) (1+0) = sm [3 .. 4] (2+(1+0)) = ... It must accumulate an intermediate stack of size O(n). Why ghc-6.10.4 computes it in a constant space (and stack) ? The following is my guess. And let the Haskell experts correct me, please. In the Haskell-98 library it is defined that (+) is strict on the type of Int (right?). Therefore, the compiler optimizes (1+0) by replacing it immediately with 1. Taking in account that all other parts are computed lazily, the evaluation of the compiled program is like this: sm [1 .. 4] 0 = sm (1:[2 .. 4]) 0 = sm [2 .. 4] (1+0) = sm [2 .. 4] 1 = sm (2: [3 .. 4]) 1 = sm [3 .. 4] (2+1) = sm [3 .. 4] 3 = ... So, it is the result of combining of the evaluation definition with a certain compiler's optimization related to the strictness info for Int.(+). Right? As to sum', it still takes O(n) space -- in ghc-6.10.4. I think, this is because it is difficult for a compiler to guess how strictness of Int.(+) may correlate to the definition of sum'. Probably, it needs some kind of inductive reasoning about sum' to optimize it (for example) into sum2. Right ? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.10.4-pre test
Dear GHC developers, I have tested ghc-6.10.3.20090628 on Debian Linux, i-386-kind machine. There were only two tests: 1) making from source by itself 2) making DoCon and running its test (without profiling). It looks all right. With kind regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
comprehension vs `map'
Dear GHC team,
I would like to write
[rl {ruleMode = AlwaysApply} | rl <- rules calc](I)
instead of map (\ rl -> rl {ruleMode = AlwaysApply}) $ rules calc (II)
and instead of
let rs = rules calc in [rl {ruleMode = AlwaysApply} | rl <- rs] (III).
But is this reliable in GHC that the compiler converts (I) into something
which is not not worse than III ?
What about other implementations?
Regards,
---
Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.10.3-pre
Dear GHC team, I have tested ghc-6.10.2.20090430 under Debian Linux, processor = (GenuineIntel cpu family 6, Intel(R) Core(TM)2 CPU 6400). It looks all right. The test was: 1) making ghc-6.10.2.20090430 from source by ghc-6.10.2, 2) making DoCon and running its test, 3) making Dumatel-1.06-pre and running its test, also with -enable-library-profiling and a bit of time profiling (for any future occasion: profiling is important). Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
my last letter
Dear GHC team, I withdraw my last bug report. It was about processing a long list on a 64 bit machine оn GHC-6.10.2. First, I cannot reproduce (?) this bug report invitation from GHC on using +RTS -M4000m Second, I have found that the process interruption only occurs when this test program runs out of RAM. And personally, I would rather use "+RTS -M15000m -RTS" and not to consider at all the system effects after the RAM overflow. Third, I apply now a more clear example, whith [Int] instead of [Integer]: - import List (genericReplicate) main = putStr (shows res "\n") where e = -- 22, 23 ... list = genericReplicate (2^e) 1 :: [Int] rList = reverse list res = myMin $ zipWith (+) list rList myMin [] = error "\nmyMin []\n" myMin [x]= x myMin (x: y: xs) = if x > y then myMin (y: xs) else myMin (x: xs) -- ghc -O --make Test64 ./Test64 +RTS -M800m -RTS -- for 1 Gb 32 bit machine ./Test64 +RTS -M12000m -RTS -- for 16 Gb 64 bit machine The last possible e for the small machine (800 Mb) occurs 24, for the big machine (12000 Mb) occurs 27 -- which looks reasonable. The timing also looks reasonable. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing 6.10.2-candidate
I have tested ghc-6.10.1.20090314 on Debian Linux, i386-unknown, on making from source by ghc-6.10.1, making itself from source, DoCon. It looks all right. - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
./T and ./T >& log
People,
I observe the output difference in running ./Bug
and ./Bug >& log
(under Linux) for the program
import Dumatel
main = do calcInput <- readFile "List0.inp"
(putStr $ parseComputeShow calcInput)
where
parseComputeShow calcInput = concat ["t = ", showsn 3 t "\n",
"tR = ", showsn 3 tR "\n"]
where
calc = addInput_default nilParseOpts (bool rpos) calcInput
t= parse_default calc "parsing Term" "(a:nil) + (b:nil)"
tR = evaluate emptyUMRMemo AllRules calc t
-- I think, it can be reduced to much simpler one.
The error break has to occur while computing tR.
The difference is in printing or skipping of the result part before tR.
The first command outputs
-
t = ((a : nil) + (b : nil))
Bug:
substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X:
sort mismatch in substitution
-
And the second command skips (in ./log) the line of t = ...
Who can tell what is the matter?
How to have identic outputs in this example?
Thank you in advance for explanation.
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
seg-fault
Yesterday, I promised to provide a bug report with Segmentation fault on missing some method implementation. I saved this source copy. Hm ... today I still failed to reproduce this seg-fault situation! I am sorry. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
seg-fault in 6.10.1
Dear GHC team, I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain Segmentation fault. Then, I noted that in a few places the compiler warned about skipping some class member implementations in some instances. I added these implementations, and now it works correct. Are you interested in the bug report on the above part of Segmentation fault ? - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
language features in 6.10.1
The GHC team writes > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > [..] > There have been a number of significant changes since the last > major release, including: > > * Some new language features have been implemented: > * Record syntax: wild-card patterns, punning, and field disambiguation > * Generalised quasi-quotes > * Generalised list comprehensions > * View patterns > > [..] Please, where and in what chapters these 4 language features are documented? Thank you in advance for help, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
space in making 6.10.1-candidate
Another point in testing ghc-6.10.0.20081007: I make it from source on Debian Linux. On 1 Gb - 2 GHz machine, it builds in 1400 sec. On 512 Mb machine, it seems to overfill RAM, it becomes slow, and this `make' creates difficulties for other processes (like emacs editor): they start to hang, a bit, and the `top' command shows 85% RAM used by this `make', now and then (and probably it takes more, sometimes). This effect is in making ghc-6.10.0.20081007 from source by ghc-6.10.0.20080921 on Debian Linux, on 512 Mb RAM i386-like machine. This was not so in earlier GHC versions. Can this be improved? Because 512 Mb is much enough. The last messages (after which I interruptred it) is make -C compiler doc stage=2 make[2]: Entering directory `/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/compiler' /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/libraries/cabal-bin /home/mechvel/ghc/6.10cand/inst0/bin/ghc /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ libraries/bootstrapping.conf haddock --distpref dist-stage2 --haddock-option=--optghc=-DSTAGE=2 --with-haddock=/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ utils/haddock/install-inplace/bin/haddock Preprocessing library ghc-6.10.0.20081007... Running Haddock for ghc-6.10.0.20081007... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library ghc-6.10.0.20081007... make[2]: *** [doc.stage.2] .. make[1]: *** [stage2] Interruption make: *** [bootstrap2] Interruption -- Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Backspace in ghci-6.10.1-candidate
This is about testing 6.10.0.20081007. 1. DoCon works with it. 2. The question is how to `install' Backspace and UpArrow in ghci. I make it from source by 6.10-candidate and also by itself -- on Debian Linux. And ghci does not process Backspace and UpArrow. ./configure reported configure:2303: checking whether ghc has editline package configure:2314: result: no And the Debian system area shows the files /usr/lib/libedit.so.2 /usr/lib/iceape/components/libeditor.so /usr/lib/libedit.so.2.9 Please, what is wrong here? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
isTypeId, isValueId
People,
I need to implement the functions
isTypeId, isValueId :: String -> Bool
which check whether the argument fits respectively the syntax of a
type identifier and of a value identifier -- in the Haskell-98 syntax
for a program.
The argument is produced by lexLots. For example, my program applies
lexLots "ab-(f_21
-- I expect:
["ab", "-", "(", "f_21", "<", "Ab", ":", "c"]
-- 1 23 4
Then, I think, only (1), (2), (3) and (4) are type or value identifiers ...
What is the most regular expression for isTypeId, isValueId ?
I presume to consider first the Standard library, and if fail, then the GHC
library.
Thank you in advance for your advice.
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10-candidate tested
On Wed, Sep 24, 2008 at 07:18:28PM +0200, Christian Maeder wrote: > Serge D. Mechveliani wrote: > > On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: > >> Do you have libedit on your linux machine (because I haven't)? > >> > > > > I do not know what is libedit and where to find it. > > It's the library needed for editline > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline > > editline is the replacement of readline. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline > > > 1. ghc-pkg list does not show the editline package. > > 2. The arrow keys and backspace do not work in ghci. > > This is so -- on my machine, under Debian Linux. > > The advantage is ghci works without editline and readline. The > disadvantage is if you want arrow keys and backspace to work, you should > have installed http://www.thrysoee.dk/editline/ first. > > > Is this due to some deficiency in Debian Linux installation or this is > > a bug in the GHC installation? > > A (debian) package manager could install editline (and gmp) before ghc. > (Unfortunately user programs may depend on those extra libraries, too.) > As I recall, earlier, there were needed for GHC the shared libraries gmp and libreadline.so* As I understand, I need now to install the shared library editline instead of libreadline. Is this so? But maybe, the installation procedure (configure command or make install command) should search for editline, gmp, and such, and report an error if the GHC installation does not find them? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10-candidate tested
On Wed, Sep 24, 2008 at 05:32:51PM +0200, Christian Maeder wrote: > Do you have libedit on your linux machine (because I haven't)? > I do not know what is libedit and where to find it. > In order to check this: > Does "ghc-pkg list" the editline package? (And do your arrow keys and > backspace work in ghci?) > 1. ghc-pkg list does not show the editline package. 2. The arrow keys and backspace do not work in ghci. This is so -- on my machine, under Debian Linux. Dear GHC developers, can you comment, please? Is this due to some deficiency in Debian Linux installation or this is a bug in the GHC installation? Regards, - Serge Mechveliani [EMAIL PROTECTED] > > This was on Linux, Debian. I have tested ghc-6.10.0.20080921 > >> on > >> * making it by ghc-6.8.2, > >> * making it by itself, > >> * the DoCon and Dumatel applications. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10-candidate tested
This was on Linux, Debian. > I have tested ghc-6.10.0.20080921 > on > * making it by ghc-6.8.2, > * making it by itself, > * the DoCon and Dumatel applications. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.10-candidate tested
Dear GHC developers, I have tested ghc-6.10.0.20080921 on * making it by ghc-6.8.2, * making it by itself, * the DoCon and Dumatel applications. It looks all right. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
skip -O2 via-C
I take back my two recent reports about the effect of -O2, -fvia-C. Because 1) -O is sufficient, 2) there are too many issues that are more important than the behavior under -O2 and via-C. So, it is a good idea to save effort. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing ghc-6.10-candidate
On Sat, Sep 20, 2008 at 11:25:57AM +0100, Simon Marlow wrote: > Serge D. Mechveliani wrote: > > >5. The same is for -O2. But this does not gain more performance. > > -O2 -fvia-C also does not gain more performance, but leads to 7 times > > longer compilation. > > Just to be sure: are you saying that with -O2 the compile time is ok, > but when you add -fvia-C it takes 7 times longer? If so, it's probably > not a bug (we don't have any control over the speed of gcc). Here's the > bug report: > > http://hackage.haskell.org/trac/ghc/ticket/2609 > > Sergey, could you clarify please? With -O2, the compile time is ok, but when I add -fvia-C, it takes 7 times longer -- this is for ghc-6.9-earlySeptember to compile DoCon-2.12-pre. You do not control over the speed of gcc itself. But a small change in the GHC compiler may, in principle, lead to many times faster compilation by gcc of the code produced by GHC. This may occur some problem in GHC as well as some problem in gcc. This is only my observation, I do not pretend for a bug report in this case. I tried -fvia-C for curiosity: "by occasion, would it increase the code performance?". If this ratio of 7 looks curious to you, you could investigate this. And personally, I am satisfied with -O (without via-C). -- Sergey ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Instances and DoCon
On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: > On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: > > | > > | And still ghc-6.8.3 builds itself from source. > > > > I have no idea how -- Happy has been needed for some time. Maybe someone > > else does. > > It's not meant to be needed for building from a source tarball. > This should be fixed now. Dear GHC team, can you, please, provide such GHC source distributives which require possibly smaller set of programs for the user to separately pre-install? For example, do not require of the user to install Alex, Happy and Cabal. Because we write applications in Haskell. For example, the user needs to program algebra by using some CA library written in Haskell. One needs to install GHC -- and the simpler the better. In this situation, it is bad to force him to think of what is Alex or Happy, and where to find them and how to install. The least hindrance in installation makes some users to reject the tool: "Oh! looks messy, suspicious thing. I tried the binary, but it reports of wrong libarary versions. I have already spent one hough! Also these pure functional languages look restrictive ... Let me better try the Foo system". Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping instance declarations
Thank you for the explanation.
--
Sergey
On Fri, Sep 19, 2008 at 10:26:01AM +0100, Simon Peyton-Jones wrote:
> | 2. But in several places DoCon has parasitic additions
> |(similar to the below MulSemigroup (Fraction a))
> |to the context for overlapping instances.
> |These places are marked in the docon-2.12-pre source with
> |'overlaps in ghc'.
> |I would like to cancel them, similar as we now cancel the above
> |MulSemigroup (Fraction a) in the context.
> |But ghc-6.9.20080910 does not allow this.
> |So, I wonder: what is the difference?
>
> No you can't cancel them! Consider
>
> class Foo a where
> fop :: a->a
> instance Foo [a] where ...
> instance Foo [Int] where ..
>
> class Bar a where
> bop :: a -> a
>
> instance Bar [a] where
> bop = fop
>
> In the Bar [a] instance, we get a constraint (Foo [a]). It's wrong to commit
> to the Foo [a] instance, because if you are ultimately building a Bar [Int]
> instance you want the Foo [Int] instance of fop!
>
> The Right Thing is to add (Foo [a]) to the context of the Bar instance thus
>
> instance Foo [a] => Bar [a] where
> bop = fop
>
> I'll expand the user manual (in the section about overlapping instances) to
> cover this point.
>
>
> The other situation that DoCon contains is more like this:
>
> class C a where { op1,op2 :: a -> a }
> instance C [Int] where...
> instance C a => C [a] where
> op1 x = op2 x ++ op2 x
> op2 x = ...
>
> In the C [a] instance you'll see that op1 calls op2, thereby giving rise to a
> C [a] constraint. I *originally thought* that the same reasoning applied as
> above, so we should reject the program. But applying the solution I describe
> above would give
>
> instance C [a], C a => C [a] where ..
>
> which is silly. Here the Right Thing is to satisfy the C [a] constraint
> "locally", without worrying about the overlap. This is justified because
> we'll only be *in* the code for op1 in the C [a] instance if we know that 'a'
> does not match Int.
>
> Thanks for bringing this up.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testing ghc-6.10-candidate
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote on 15 Sep 2008
about Instances and DoCon
To: "Serge D. Mechveliani" <[EMAIL PROTECTED]>
CC: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Serge
>
> I take it all back. I've been persuaded that it's best to accept
> DoCon-sty le instances as they appear, and I've put quite a bit of
> work into making it so.
>
> So you should not need to change any code. Do try the HEAD
> (any recent snapshot should do) if you can.
All right, I have tested ghc-6.9.20080910 on docon-2.12-pre.
Find the source on
http://botik.ru/pub/local/Mechveliani/ghcBugs/docon-2.12-pre.zip
It is put there only for testing GHC, and it has the compilation flag
denotation in docon.cabal improved for newer Cabal and ghc-6.10.
The tet shows the followng.
1. It accepts the DoCon-style overlapping instances (as in docon-2.11)
-- in the example of ... => LinSolvRing (Fraction a)
that you pointed out below.
2. But in several places DoCon has parasitic additions
(similar to the below MulSemigroup (Fraction a))
to the context for overlapping instances.
These places are marked in the docon-2.12-pre source with
'overlaps in ghc'.
I would like to cancel them, similar as we now cancel the above
MulSemigroup (Fraction a) in the context.
But ghc-6.9.20080910 does not allow this.
So, I wonder: what is the difference?
3. `Making' under -O2 reports for the module Det_.hs several warnings
of the kind
...
[25 of 83] Compiling Det_ ( Det_.hs, dist/build/Det_.o )
SpecConstr: too many specialisations for one function
(see -fspec-constr-count):
Function: dt{v X1E1R} [lid]
Specialisations: [([sc_s1E2A{v} [lid], sc_s1E2B{v} [lid],
...
What might this mean?
4. It has improved: it `makes' docon-2.12 under -O fast enough,
without code explosion, the code is as fast as expected.
It also `makes' the test Main under -O fast enough (unlike ghc-6.8.3).
5. The same is for -O2. But this does not gain more performance.
-O2 -fvia-C also does not gain more performance, but leads to 7 times
longer compilation.
Anyway, I am satisfied with -O.
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
---
| Good news: I have cured the massive code-explosion problem you
| encountere with GHC 6.8. I'm
| about to commit a patch for that, so it'll be in GHC 6.10.
|
| However, I'm now getting a complaint about overlapping instances
| (DoCon 2.11). GHC 6.10 is
| being a bit more consistent about coherence. Here is one example:
|
| Fraction.hs:124:48:
| Overlapping instances for MulSemigroup (Fraction a)
| arising from a use of `inv' at Fraction.hs:124:48-57
| Matching instances:
| instance [overlap ok] (GCDRing a) =3D> MulSemigroup (Fraction a)
| -- Defined at Fract_.hs:438:9-46
| instance [overlap ok] MulSemigroup (Fraction Integer)
| -- Defined at Fraction.hs:260:9-39
| (The choice depends on the instantiation of `a'
| To pick the first instance above, use -XIncoherentInstances
| when compiling the other instance declarations)
|
| It's absolutely right! If you wanted the instance for
| (MulSemigroup (Fraction Integer)), then
| the call to inv could in principle use
| MulSemigroup (Fraction Integer) instance, and give
| different behaviour. (See the user manual stuff about incoherent-
| instances.)
|
| Possible solutions:
| a) add -XAllowIncoherentInstances
| b) make the instance declaration look like
| instance (MulSemigroup (Fraction a), GCDRing a) =>
|LinSolvRing (Fraction a)
|thereby deferring the choice
[..]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: making Happy-1.17
On Wed, Sep 17, 2008 at 11:10:17AM +0100, Simon Peyton-Jones wrote: > Why not grab a binary distribution? > > [..] > | cd ~/happy/happy-1.17/ > | runhaskell Setup.lhs configure -v --ghc > | --prefix=/home/mechvel/happy/happy-1.17/inst I thank people who advised me on my recent request about installing GHC snapshot and Happy. The result of the whole investigation is as follows. 1. Installing ghc-6.9.20080907-i386-unknown-linux.tar.bz2 (from binary) leads to ./configure --prefix=... make install - ... installPackage: Saved package config file seems to be corrupt. Try re-running the 'configure' command. --- 2. To `make' a ghc-6.9 snapshot from source by GHC, I need to first install Happy and Alex. 3. I discovered that the simplest way to install Happy and Alex on my Debian Linux, i386 is to command apt-get install happy apt-get install alex -- because they are in the Debian Linux distributive. Now, `making' of ghc-6.9.. is in progress, I hope, it will succeed. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
making Happy-1.17
Dear team of Happy, Please, where to find the `make' instruction for Happy-1.17 ? How to `make' it from source on Linux, i386 ? I have ghc-6.8.3 installed, and Cabal. As I see happy.cabal, maybe, Happy can be `made' similarly as I make (with Cabal and GHC) my programs under GHC (?). So, I command cd ~/happy/happy-1.17/ runhaskell Setup.lhs configure -v --ghc --prefix=/home/mechvel/happy/happy-1.17/inst It reports Configuring happy-1.17... Setup.lhs: At least the following dependencies are missing: mtl >=1.0 Please, help, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
making 6.9.. with 6.8.3
Dear GHC team, I again have problems with making GHC from source. Now, this is for making ghc-6.9.20080910-src.tar.bz with ghc-6.8.3. ./configure --prefix=... reports that Happy is needed. But earlier, I compiled ghc-6.8.3 with itself, and it did not required Happy. Generally, as I recall, I got used to making GHC from source without installing Happy. Please, what (and why) has changed about this? Maybe ghc-6.8.3 has Happy inside it and ghc-6.9.20080910-src has not? Here are the fragments of config.log for ghc-6.8.3 auto-make: --- ... It was created by The Glorious Glasgow Haskell Compilation System configure 6.8.3, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/home/mechvel/ghc/6.8.3/inst ## - ## ## Platform. ## ## - ## hostname = scico uname -m = i686 uname -r = 2.6.22-1-686 uname -s = Linux uname -v = #1 SMP Mon Jul 23 13:23:02 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/mechvel/ghc/6.8.3/inst1/bin ... ... configure:5565: result: /home/mechvel/ghc/6.8.3/inst1/bin/ghc-pkg configure:5707: checking for happy configure:5740: result: no configure:5744: checking for version of happy configure:5757: result: configure:5794: checking for haddock configure:5827: result: no configure:5837: checking for alex configure:5870: result: no configure:5874: checking for version of alex configure:5887: result: ... ... #define _FILE_OFFSET_BITS 64 configure: exit 0 --- Why ghc-6.9.20080910-src.tar.bz cannot produce such? What I am missing? Can you somehow preserve the `make' procedure between the versions? Second, several years ago I was able to `make' Happy. Now, I tried to make Happy-1.17, with ghc-6.8.3. But it occurs difficult to find out how to do this. This is not like with GHC. The source GHC has README in the root of the `make' directory, where it is visible an short instruction ./configure ... make make install And in Happy, I do not find such. I am unhappy with Happy. Please, advise, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
