Re: Newtype wrappers
On Mon, Jan 14, 2013 at 7:09 PM, Simon Peyton-Jones simo...@microsoft.comwrote: Friends ** ** I’d like to propose a way to “promote” newtypes over their enclosing type. Here’s the writeup http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers ** ** Any comments? Below is the problem statement, taken from the above page. Have you considered the effect on types like Data.Set that use the uniqueness of typeclass instances to maintain invariants? e.g. even when we have newtype X = X Y coercing Set X to Set Y can produce a tree with the wrong shape for the Ord instance of Y. -- Andrea ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing binary tarball fails on Linux
On Thu, Feb 23, 2012 at 10:27 PM, Johan Tibell johan.tib...@gmail.com wrote: The 64-bit version work so I guess that means that a 32-bit GHC/64-bit OS combination only works on OS X? Did you get it working on linux? I'm getting the same error myself: ... ghc-cabal: Bad interface file: dist-install/build/GHC/Classes.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 -- Andrea ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?
On Sun, Sep 16, 2012 at 5:49 PM, Simon Peyton-Jones simo...@microsoft.com wrote: [...] Type inference ~ I'm a little unclear about the implications for inference. One route might be this. Suppose we are trying to solve a constraint [W] (a:'(k1,ks)) ~ '( t1, t2 ) where a is an untouchable type variable. (if it was touchable we'd simply unify it.) Then we can replace it with a constraint [W] '(Fst a, Snd a) ~ '( t1, t2) Is that it? Or do we need more? I'm a bit concerned about constraints like F a ~ e where a:'(k1,k2), and we have a type instance like F '(a,b) = ... F a ~ F '(Fst a, Snd a) has to hold, so one does need to expand a for constraints like F a ~ e in this case. One way to think of it is that patterns like '(a,b) are the same as value-level ~(a,b) ones. -- Andrea ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module
I've pushed the discussed changes to the repo[1], it'd be good if you (and other users) could test them before they get to hackage. [1] darcs get http://patch-tag.com/r/Saizan/syb-with-class/ -- Andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?
On Mon, Sep 3, 2012 at 9:26 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
[...]
So, it seems possible to introduce eta coercions into FC for all kinds
containing only one type constructor without sacrificing soundness. How the
type inference engine/source Haskell triggers the use of these coercions is
another matter, but there doesn't seem to be anything fundamentally wrong
with the idea.
A recent snapshot of ghc HEAD doesn't seem to agree:
{-# LANGUAGE GADTs, KindSignatures, PolyKinds, DataKinds,
TypeFamilies, ScopedTypeVariables, TypeOperators #-}
import GHC.Exts
import Unsafe.Coerce
data (:=:) :: k - k - * where
Refl :: a :=: a
trans :: a :=: b - b :=: c - a :=: c
trans Refl Refl = Refl
type family Fst (x :: (a,b)) :: a
type family Snd (x :: (a,b)) :: b
type instance Fst '(a,b) = a
type instance Snd '(a,b) = b
eta :: x :=: '(Fst x, Snd x)
eta = unsafeCoerce Refl
-- ^^^ this is an acceptable way to simulate new coercions, i hope
type family Bad s t (x :: (a,b)) :: *
type instance Bad s t '(a,b) = s
type instance Bad s t Any = t
refl_Any :: Any :=: Any
refl_Any = Refl
cong_Bad :: x :=: y - Bad s t x :=: Bad s t y
cong_Bad Refl = Refl
s_eq_t :: forall (s :: *) (t :: *). s :=: t
s_eq_t = cong_Bad (trans refl_Any eta)
subst :: x :=: y - x - y
subst Refl x = x
coerce :: s - t
coerce = subst s_eq_t
{-
GHCi, version 7.7.20120830: http://www.haskell.org/ghc/ :? for help
*Main coerce (4.0 :: Double) :: (Int,Int)
(Segmentation fault
-}
-- Andrea Vezzosi
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module
On Mon, Sep 3, 2012 at 12:00 PM, Roman Cheplyaka r...@ro-che.info wrote:
There's a bug in syb-with-class reported by Alexey Rodriguez Yakushev in
2008 [1]. I can confirm that the bug is still there (syb-with-class-0.6.1.3,
ghc 7.4.1).
[1]: http://www.haskell.org/pipermail/haskell-cafe/2008-March/041179.html
Here's an even simpler test case:
{-# LANGUAGE FlexibleContexts, FlexibleInstances, MultiParamTypeClasses,
UndecidableInstances, TemplateHaskell, OverlappingInstances,
DeriveDataTypeable #-}
import Data.Generics.SYB.WithClass.Basics
import Data.Generics.SYB.WithClass.Derive
data Foo = Foo Foo | Bar
deriving (Typeable, Show)
deriveData [''Foo]
f :: (Data NoCtx ast, Typeable ast) = ast - TypeRep
f = typeOf
main = print $ f $ Foo Bar
This is pretty similar to what ended up being a ghc bug, fixed in 7.0 though:
http://hackage.haskell.org/trac/ghc/ticket/3731
The cause of this bug is a self-referencing instance created by
deriveData:
instance (Data ctx Foo, Sat (ctx Foo)) = Data ctx Foo where ...
What's the proper way to fix it?
From a few tests it seems we no longer need the circular context hack
in ghc-7.4.1 to get the instance to typecheck, so we could side-step
the issue entirely by removing it from the generated code.
-- Andrea Vezzosi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module
On Mon, Sep 3, 2012 at 2:53 PM, Roman Cheplyaka r...@ro-che.info wrote: * Andrea Vezzosi sanzhi...@gmail.com [2012-09-03 12:50:03+0200] [...] This is pretty similar to what ended up being a ghc bug, fixed in 7.0 though: http://hackage.haskell.org/trac/ghc/ticket/3731 The difference between my test case and the one attached to the ticket is that here there's an explicitly circular instance generated by TH. In the SYB with class paper it is specifically said to be broken. So it looks more like a problem in the TH code rather than in GHC. Right, it's debatable whether ghc should support these instances, though in our case they are well-founded, it only has to produce code that's lazy enough on the dictionaries as far as i can tell. The cause of this bug is a self-referencing instance created by deriveData: instance (Data ctx Foo, Sat (ctx Foo)) = Data ctx Foo where ... What's the proper way to fix it? From a few tests it seems we no longer need the circular context hack in ghc-7.4.1 to get the instance to typecheck, so we could side-step the issue entirely by removing it from the generated code. Not sure what hack you're referring to. I was going from memory and remembering that the additional Data ctx Foo in the context was necessary to make the instance typecheck, and calling that an hack. (Now I think I was remembering some HappS code using syb-wc which had to do that instead). As I understand it, the circular context arises as a special case of the context that includes all the inner types of a data type. It's not possible to get rid of this context entirely — for example, consider data X a = X (Y a) where we really need the Data ctx (Y a) context (but perhaps it could be Data ctx a instead?). (I don't think I like changing the produced code on the basis of which instances are in scope, so I'd stick with Data ctx (Y a)) So we need some criterion to decide whether a structural part of a data type should be included into the instance context. Does this make sense, or am I on the completely wrong track? Yes that's correct, I meant to only filter out Data ctx (X a) in this case, in general I propose to eliminate all the Data ctx (X ..) from the context, when X is the data constructor for which we are making the instance, but keep the corresponding Sat (ctx (X ..)), do you think this would break any instances that would otherwise work? It'd be interesting to find out if we can make a sensible instance for non-regular types like the following though: data Z a = Z (Z (a,a)) | Leaf a the instance we produce currently makes instance resolution non-terminate and the instance we'd produce under my proposal wouldn't typecheck. -- Andrea Vezzosi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: TypeFamilies vs. FunctionalDependencies type-level recursion
On Tue, Jun 14, 2011 at 4:40 PM, Dan Doel dan.d...@gmail.com wrote:
On Tue, Jun 14, 2011 at 5:36 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
There was an interesting thread on haskell-prime [1], about the relationship
between functional dependencies and type families. This message is my
attempt to summarise the conclusions of that thread. I'm copying other
interested parties (eg Oleg, Dimitrios)
[1] http://www.haskell.org/pipermail/haskell-prime/2011-May/003416.html
1. As things stand in GHC you can do some things with functional
dependencies that you can't do with type families. The archetypical example
is type equality. We cannot write
type family Eq a b :: *
type instance Eq k k = True
type instance Eq j k = False
because the two instances overlap. But you can with fundeps
class Eq a b c | a b - c
instance Eq k k True
instance Eq j k False
As Alexey mentioned, fundeps have other disadvantages, so it's reasonable to
ask whether type families could extend to handle cases like this.
Fundeps no longer allow this as of GHC 7, it seems. It causes the same
fundep violation as the case:
class C a b | a - b
instance C a R
instance C T U
Are you sure that worked before? The following still does anyhow:
{-# LANGUAGE MultiParamTypeClasses, OverlappingInstances,
FunctionalDependencies
, EmptyDataDecls, FlexibleInstances,
UndecidableInstances #-}
class TypeCast a b | a - b, b-a where typeCast :: a - b
class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b
class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b
instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' () x
instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
data R
data T
data U
class C a b | a - b
instance TypeCast R b = C a b
instance TypeCast U b = C T b
In fact this is how IsFunction was implemented in 2005[1], and the
same transformation appears to work for the Eq class too.
If we allow TypeFamilies we can use (~) instead of the TypeCast hack,
fortunately.
[1] http://okmij.org/ftp/Haskell/isFunction.lhs
-- Andrea
for R /~ U. Which I find somewhat sensible, because the definitions
together actually declare two relations for any type:
Eq T T False
Eq T T True
and we are supposed to accept that because one is in scope, and has a
particular form, the other doesn't exist. But they needn't always be
in scope at the same time.
Essentially, GHC 7 seems to have separated the issue of type-function
overlapping, which is unsound unless you have specific conditions that
make it safe---conditions which fundeps don't actually ensure (fundeps
made it 'safe' in the past by not actually doing all the computation
that type families do)---from the issue of instance overlapping, which
is always sound at least. But if I'm not mistaken, type families can
handle these cases.
I'd personally say it's a step in the right direction, but it probably
breaks a lot of HList-related stuff.
-- Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Set monad
On Sun, Jan 9, 2011 at 7:45 AM, Sebastian Fischer fisc...@nii.ac.jp wrote: [...] Only conversion to the underlying Set type requires an Ord constraint. getSet :: Ord a = Set a - S.Set a getSet a = a - S.singleton this unfortunately also means that duplicated elements only get filtered out at the points where you use getSet, so in getSet ((return 1 `mplus` return 1) = k) k gets still called twice ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Possible bug with GADTs?
On Tue, Aug 17, 2010 at 8:54 PM, Dan Knapp dan...@gmail.com wrote:
Below, please find a snippet from a program I'm working on, and the
error it produces. I was told in #haskell that this was pretty
suspect and could conceivably be a ghc bug. So I'm reporting it
here. I'd also be grateful for workarounds.
[...]
I've just found a fairly simple one: make instance resolution happen
where the equality constraints are not in scope.
{-# LANGUAGE GADTs #-}
data TemplateValue a where
TemplateList :: [a] - TemplateValue [a]
instance Eq a = Eq (TemplateValue a) where
(==) = eqBy (==)
eqBy :: (a - a - Bool) - TemplateValue a - TemplateValue a - Bool
eqBy (==) (TemplateList xs) (TemplateList ys) = xs == ys
I've also found that, surprisingly at this point, the following typechecks:
eq :: Eq a = TemplateValue a - Bool
eq (TemplateList xs) = xs == xs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Thu, May 13, 2010 at 8:13 PM, wren ng thornton w...@freegeek.org wrote: Andrea Vezzosi wrote: On Thu, May 13, 2010 at 10:51 AM, wren ng thornton w...@freegeek.org wrote: Andrea Vezzosi wrote: wren ng thornton wrote: With this change [1] I can't notice any difference for your benchmark[2]. Then again, all the runTest calls take 0 msec and I've had no luck making the computation take much time; perhaps your computer can detect a difference. On my machine, with ghc-6.12.1, yours and the original ErrCPS give quite similar results, both ~2x slower than Either. However it's important to note that these results are highly dependent on the monadic expressions being evaluated, with a different benchmark you can get an huge speedup with the CPS versions. That's very curious. After installing Criterion, my machine (OSX 10.5.8 2.8GHz Intel Core2Duo, GHC 6.12.1 with -O2) shows only 1% difference between my ErrCPS and Either on this benchmark. Alas, I can't print kernel density graphs since Crieterion charts are broken on 6.12. It seems buggy that your platform would behave so much differently... I got the measurements from the original code, could you share the code that uses criterion instead? The 1% number was buggy because I hadn't factored the generation of random lists out of the benchmark. But, having fixed that, I still can't replicate your numbers: I get 12us for Either, vs 17us for EitherCPS. http://community.haskell.org/~wren/wren-extras/test/Control/Monad/ErrCPS/CriterionBenchmark.hs Yet another version of the same benchmark, this time using Microbench: http://community.haskell.org/~wren/wren-extras/test/Control/Monad/ErrCPS/MicrobenchBenchmark.hs Microbench seems to replicate your numbers better: 2551.930ns vs 4466.832ns (or 391.86 vs 223.87 calls per second)--- though this is getting into the range where there might be Int overflow issues corrupting the results (a similar problem showed up when benchmarking Data.Trie vs Data.Map), so it may warrant further investigation. That might be the case, i'm on 64bit: sai...@astarte:~$ uname -a Linux astarte 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux sai...@astarte:~$ ./CriterionBenchmark warming up estimating clock resolution... mean is 6.834442 us (80001 iterations) found 1240 outliers among 79998 samples (1.6%) 1131 (1.4%) high severe estimating cost of a clock call... mean is 107.2316 ns (41 iterations) benchmarking Either collecting 100 samples, 1039 iterations each, in estimated 683.8220 ms bootstrapping with 10 resamples mean: 6.563462 us, lb 6.553649 us, ub 6.570454 us, ci 0.950 std dev: 41.74602 ns, lb 23.76971 ns, ub 67.67842 ns, ci 0.950 found 8 outliers among 100 samples (8.0%) 2 (2.0%) low severe 4 (4.0%) high mild 2 (2.0%) high severe variance introduced by outliers: 0.990% variance is unaffected by outliers benchmarking ErrCPS collecting 100 samples, 1 iterations each, in estimated 1.334000 s bootstrapping with 10 resamples mean: 13.14468 ms, lb 13.10442 ms, ub 13.18208 ms, ci 0.950 std dev: 198.3150 us, lb 182.0600 us, ub 220.7957 us, ci 0.950 variance introduced by outliers: 0.993% variance is unaffected by outliers If i'm reading it correctly this gives even worse results: 6us vs. 13ms -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Thu, May 13, 2010 at 10:51 AM, wren ng thornton w...@freegeek.org wrote: Andrea Vezzosi wrote: wren ng thornton wrote: With this change [1] I can't notice any difference for your benchmark[2]. Then again, all the runTest calls take 0 msec and I've had no luck making the computation take much time; perhaps your computer can detect a difference. On my machine, with ghc-6.12.1, yours and the original ErrCPS give quite similar results, both ~2x slower than Either. However it's important to note that these results are highly dependent on the monadic expressions being evaluated, with a different benchmark you can get an huge speedup with the CPS versions. That's very curious. After installing Criterion, my machine (OSX 10.5.8 2.8GHz Intel Core2Duo, GHC 6.12.1 with -O2) shows only 1% difference between my ErrCPS and Either on this benchmark. Alas, I can't print kernel density graphs since Crieterion charts are broken on 6.12. It seems buggy that your platform would behave so much differently... I got the measurements from the original code, could you share the code that uses criterion instead? mkEMA is in fact quite peculiar, since there's no catchError and the throwError call is rarely (or never?) made, and thanks to foldM you get that (=) is only used in a right associated way, which is the ideal situation for Either. Indeed, mkEMA is a sort of worst-case comparison that doesn't take advantage of the ability to short-circuit. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers
On Wed, May 12, 2010 at 7:50 AM, wren ng thornton w...@freegeek.org wrote:
wren ng thornton wrote:
Here's one big difference:
newtype ErrCPS e m a = ErrCPS { runErrCPS ::
forall r . (e - m r) -- error handler
- (a - m r) -- success handler
- m r }
The analogous version I use is:
newtype MaybeCPS a = MaybeCPS
(forall r. (a - Maybe r) - Maybe r)
While I also offer a transformer version of MaybeCPS, the transformer
*does* suffer from significant slowdown. Also, for MaybeCPS it's better to
leave the handlers inline in client code rather than to abstract them out;
that helps to keep things concrete. So perhaps you should first try a direct
CPS translation:
newtype ErrCPS e a = ErrCPS
(forall r. (a - Either e r) - Either e r)
runErrCPS :: ErrCPS e a - Either e a
runErrCPS (ErrCPS f) = f return
I'd be curious if this version suffers the same slowdown.
With this change [1] I can't notice any difference for your benchmark[2].
Then again, all the runTest calls take 0 msec and I've had no luck making
the computation take much time; perhaps your computer can detect a
difference.
On my machine, with ghc-6.12.1, yours and the original ErrCPS give
quite similar results, both ~2x slower than Either.
However it's important to note that these results are highly dependent
on the monadic expressions being evaluated, with a different benchmark
you can get an huge speedup with the CPS versions.
mkEMA is in fact quite peculiar, since there's no catchError and the
throwError call is rarely (or never?) made, and thanks to foldM you
get that (=) is only used in a right associated way, which is the
ideal situation for Either.
In a larger program one might mix the two to get the best of both
worlds i guess, and maybe we can make a library where each combinator
from Control.Monad is reimplemented with the most fitting alternative
behind the scenes.
the nice part is that you can get the CPS version in a generic way
using Codensity:
http://hackage.haskell.org/packages/archive/mmtl/0.1/doc/html/Control-Monad-Codensity.html
You may want to see what standard benchmarking tools like Microbench[3] or
the magnificent Criterion[4] have to say. I'd do it myself, but I haven't
had a chance to reinstall everything since getting my new computer (due to
the installation issues on newer versions of OSX).
[1]
http://community.haskell.org/~wren/wren-extras/src/Control/Monad/ErrCPS.hs
[2]
http://community.haskell.org/~wren/wren-extras/test/Control/Monad/ErrCPS/MaxCantorBenchmark.hs
[3] http://hackage.haskell.org/package/microbench
[4] http://hackage.haskell.org/package/criterion
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SYB looping very, very mysteriously
On Mon, Dec 7, 2009 at 3:38 PM, David Fox dds...@gmail.com wrote: On Sat, Dec 5, 2009 at 2:38 AM, Andrea Vezzosi sanzhi...@gmail.com wrote: On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw jer...@n-heptane.com wrote: I have stripped things down to the bare minimum, and test under GHC 6.10, GHC 6.12, Linux, and Mac OS X. Results are consistent. In the following code, 1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine 2. if you change the gunfold instance for Proposition to, error gunfold it stops hanging -- even though this code is never called. 3. if you change, ( Data ctx [Expression], Sat (ctx Expression) = Data ctx Expression, to (Data ctx Expression, ) = ... it stops hanging. If someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there... It's less of a mystery if you think about the actual dictionaries ghc uses to implement typeclasses. The instance for Data ctx [a] depends on Data ctx a, so by requiring Data ctx [Expression] in the Data ctx Expression instance you're indeed making a loop there, though typeclasses do allow this, and the implementation has to be lazy enough to permit it. Strange that with a direct Data ctx Expression = Data ctx Expression loop we don't get the same problem. The reason the implementation of Proposition's gunfold matters is probably that k gets passed the dictionary for Data DefaultD Expression at the site of its call and some optimization is making it stricter than necessary. Looks like we need a ghc dev here to fully unravel the mystery, in the meantime i'll try to reduce the test case even further. I have posted a ghc bug for this: http://hackage.haskell.org/trac/ghc/ticket/3731 and an syb-with-class bug, in case it is not a ghc bug (perhaps due to undecidable instances?):http://code.google.com/p/syb-with-class/issues/detail?id=3 While trying to make the test case on the ghc trac self-contained I've found a workaround which involves changing the Default [a] instance in happstack-data. I've attached the patch. I don't know why it works with certainity, so it'd be nice if you could test it in a large codebase at least. The problem is that one should work out how all these dictionaries get constructed, and that means staring at a lot of Core. workaround-for-default-wrt-http___hackage_haskell_org_trac_ghc_ticket_3731.dpatch Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SYB looping very, very mysteriously
On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw jer...@n-heptane.com wrote:
I have stripped things down to the bare minimum, and test under GHC 6.10,
GHC 6.12, Linux, and Mac OS X. Results are consistent.
In the following code,
1. if you load the code into ghci and evaluate e it will hang, but
(defaultValueD dict) :: Expression returns fine
2. if you change the gunfold instance for Proposition to, error gunfold
it stops hanging -- even though this code is never called.
3. if you change, ( Data ctx [Expression], Sat (ctx Expression) = Data ctx
Expression, to (Data ctx Expression, ) = ... it stops hanging.
If someone could explain why each of these cases perform as they do, that
would be awesome! Right now it is a big mystery to me.. e calls dict .. and
there is only one instance of dict available, which should call error right
away. I can't see how something could get in the way there...
It's less of a mystery if you think about the actual dictionaries ghc
uses to implement typeclasses.
The instance for Data ctx [a] depends on Data ctx a, so by requiring
Data ctx [Expression] in the Data ctx Expression instance you're
indeed making a loop there, though typeclasses do allow this, and the
implementation has to be lazy enough to permit it.
Strange that with a direct Data ctx Expression = Data ctx Expression
loop we don't get the same problem.
The reason the implementation of Proposition's gunfold matters is
probably that k gets passed the dictionary for Data DefaultD
Expression at the site of its call and some optimization is making it
stricter than necessary.
Looks like we need a ghc dev here to fully unravel the mystery, in the
meantime i'll try to reduce the test case even further.
- jeremy
{-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances,
MultiParamTypeClasses, UndecidableInstances, RankNTypes,
ScopedTypeVariables, KindSignatures, EmptyDataDecls,
NoMonomorphismRestriction #-}
module Main where
import qualified Data.Data as Data
import Data.Typeable
--- syb-with-class
data Constr = Constr deriving (Eq, Show)
data Proxy (a :: * - *)
class Sat a where
dict :: a
class (Typeable a, Sat (ctx a)) = Data ctx a where
gunfold :: Proxy ctx
- (forall b r. Data ctx b = c (b - r) - c r)
- (forall r. r - c r)
- Constr
- c a
instance (Sat (ctx [a]),Data ctx a) = Data ctx [a]
--- Default
class (Data DefaultD a) = Default a where
defaultValue :: a
data DefaultD a = DefaultD { defaultValueD :: a }
instance Default t = Sat (DefaultD t) where
dict = error Sat (DefaultD t) not implemented
instance Default a = Default [a] where
defaultValue = error Default [a] not implemented
--- Trouble
data Proposition = Proposition Expression deriving (Show, Data.Data,
Typeable)
data Expression = Conjunction Expression deriving (Show, Data.Data,
Typeable)
-- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx
Proposition)) = Data ctx Proposition where
instance Data DefaultD Proposition where
gunfold _ k z c = k (z Proposition)
-- gunfold _ k z c = error gunfold
instance Default Proposition
-- Change Data ctx [Expression] to Data ctx Expression and main works.
instance ( Data ctx [Expression]
, Sat (ctx Expression)
) = Data ctx Expression
instance Default Expression
e :: Expression
e = defaultValueD (dict :: DefaultD Expression)
main = print e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1
On Mon, Oct 12, 2009 at 6:43 PM, Christian Maeder christian.mae...@dfki.de wrote: Hi, with http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ghc-6.12.0.20091010-i386-unknown-linux-n.tar.bz2 installed (under /local/maeder/) I get the following internal Haddock or GHC error. I have no file /local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css but a file /local/maeder/share/doc/ghc/html/html/haddock.css I've the same problem, it seems that haddock's data-files are not installed anywhere by ghc's build system, even if they are present in the tarball under utils/haddock. /local/maeder/share/doc/ghc/html/html/haddock.css seems to be the .css for the main documentation index, i don't think it makes sense for haddock to take the default files from there. A workaround could be a separate installation of haddock (assuming it'll look for the files where cabal will install them), but i couldn't find a ghc-paths updated for 6.12. and I run: ./Setup configure -O --prefix=/local/maeder ./Setup build ./Setup haddock ./Setup install Cheers Christian P.S. I wonder why Registering is done twice Configuring packedstring-0.1.0.1... Preprocessing library packedstring-0.1.0.1... Building packedstring-0.1.0.1... [1 of 1] Compiling Data.PackedString ( Data/PackedString.hs, dist/build/Data/PackedString.o ) Registering packedstring-0.1.0.1... Running Haddock for packedstring-0.1.0.1... Preprocessing library packedstring-0.1.0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 haddock: internal Haddock or GHC error: /local/maeder//lib/ghc-6.12.0.20091010/html/haddock.css: openFile: does not exist (No such file or directory) Installing library in /local/maeder/lib/packedstring-0.1.0.1/ghc-6.12.0.20091010 Registering packedstring-0.1.0.1... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.4 Release Candidate 1
the bug about ^C (http://hackage.haskell.org/trac/ghc/ticket/3317) doesn't look fixed to me, on amd64 linux. sai...@astarte:~/cabal$ ~/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3.20090628 sai...@astarte:~/cabal$ ~/bin/ghc --make foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... sai...@astarte:~/cabal$ ./foo ^Ca a b b ^C cat: -: Input/output error sai...@astarte:~/cabal$ where foo.hs is the code from the ticket. On Wed, Jul 1, 2009 at 1:19 PM, Ian Lynaghig...@earth.li wrote: We are pleased to announce the first release candidate for GHC 6.10.4: http://www.haskell.org/ghc/dist/6.10.4-rc1/ We have now fixed all the bugs that we intend to fix for 6.10.4, so if there is a bug that is important to you that hasn't been fixed in the release candidate, please let us know. The release notes are here: http://www.haskell.org/ghc/dist/6.10.4-rc1/release-6-10-4.html The directory above contains two source bundles: ghc-6.10.3.20090628-src.tar.bz2 ghc-6.10.3.20090628-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. 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
Re: [Haskell-cafe] Re: Completely confused by cabal
On Sun, Mar 22, 2009 at 12:51 PM, Colin Paul Adams co...@colina.demon.co.uk wrote: Achim == Achim Schneider bars...@web.de writes: Achim Colin Paul Adams co...@colina.demon.co.uk wrote: So why doesn't it find packages then, when they are installed? Achim I've got no idea, what exactly are you trying to do, and Achim how? I'm trying to re-compile ghc 6.11 and it doesn't find parsec. when cabal is invoked by root, like in su -c cabal ... or su -c runghc Setup ..., it won't see the user packagedb, but there's rarely a reason to do so. Usually only the install phase needs to be done as root, while building and configuring can be done as user. For ghc you'd want to run ./configure and make as user and make install as root. For normal packages, if you want to install them system wide, you'd use something like cabal install --global --root-cmd=sudo foo You can make those flags the default with user-install: False root-cmd: sudo in ~/.cabal/config If you still have problems it'd be interesting to see what are the initial commands that were failing in your attemt to build ghc-6.11. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Completely confused by cabal
I should clarify that cabal install --global won't see the packages installed in the user db, even if not run as root. But it at least will take into consideration the available packages' cache and the config file in ~/.cabal/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
2009/3/6 Daryoush Mehrtash dmehrt...@gmail.com: Two questions: a) This chat server implementation doesn't actually close the connection as a real one would need to do. If you use forever is there a way to end the loop so as to end the connection? Yes, throw an exception and catch it from outside the forever. b) In Section 5 of this paper: http://www.cs.yale.edu/~hl293/download/leak.pdf Comparing the definition of eSF and e reveals that the primary difference is in the fixed-point operators they use. e uses Haskell’s built-in fixed-point operator, which is equivalent to the standard: fix f = f (fix f) eSF, on the other hand, is defined in terms of the loop combinator, which ties the loop tighter than the standard fixed-point operator. In particular, note in Figure 6 that loop computes the value-level fixed point as z, but re-uses itself in the continuation part. This is the key to avoiding the space leak. My reading is that the fix operator, at least in some cases, causes space leak. Where as the arrow's loop, which uses let model, doesn't have this issue. Question: Do I need to worry about space leak if I am using the fix to instead of the let? the definition of fix in Data.Function[1] actually uses let: fix :: (a - a) - a fix f = let x = f x in x [1] http://darcs.haskell.org/packages/base/Data/Function.hs Thanks Daryoush 2009/3/5 Luke Palmer lrpal...@gmail.com On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
2009/2/22 Luke Palmer lrpal...@gmail.com: On Sun, Feb 22, 2009 at 8:15 AM, John Meacham j...@repetae.net wrote: On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) The ghc-api exposes a type for annotated source: http://haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t%3ATypecheckedSource Not that i know how to use it. Luke in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trying to install Cabal
the solution here is to compile Setup.hs with ghc first, i.e. ghc
--make Setup.hs and then use the produced Setup.exe, this is also
recommended un linux since runghc will have to load and interpret many
modules if not.
However if you've already built cabal-install against 1.6.0.1 you can
simply cabal update and then cabal install Cabal cabal-install to
get both working with the latest code.
On Fri, Feb 20, 2009 at 3:19 PM, David dfket...@gmail.com wrote:
Hi!
I've just installed ghc (v 6.10.1) for Windows, and it seems to be
installed correctly, and now I'm trying to install Cabal (v1.6.0.2),
but I'm getting the following error message (along with a lot of
warnings about a deprecated something-or-other, which I assume I can
ignore):
C:\Temprunghc Setup configure -p
Distribution\Simple\Utils.hs:1:11:
Warning: -fffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
Distribution\Simple\Utils.hs:4:15:
Warning: -fffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
Distribution\Simple\InstallDirs.hs:1:11:
Warning: -fffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
Distribution\Simple\InstallDirs.hs:4:15:
Warning: -fffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
During interactive linking, GHCi couldn't find the following symbol:
shgetfolderpa...@20
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-b...@haskell.org
Am I missing a dependency, or is ghc not installed properly, or am I
doing something else wrong?
Thanks,
David.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Bug in Cabal?
On Tue, Feb 17, 2009 at 11:50 PM, Achim Schneider bars...@web.de wrote: Martin Huschenbett hus...@gmx.org wrote: $ cabal install ghci-haskeline Resolving dependencies... cabal.exe: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 cabal uninstall process-1.0.1.1 is what you want to do, except cabal uninstall doesn't exist (yet) and you meant ghc-pkg unregister i guess. and never, ever[1] use cabal upgrade. If you're interested in the gory details and why it's a bug while at the same time not being one, there's a lengthy thread starting with http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/51759 [1] Until cabal becomes smarter -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
I did work on this and i simplified the code a lot fixing inconsistencies and making more explicit what how each component contributes to the arguments to haddock. Aside from this, should we also do the unliting and cpp from Cabal on the sources passed to HsColour? On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote: 2009/2/6 Alistair Bayley alist...@abayley.org: [1 of 1] Compiling Test.Fail( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' Are you processing the above module but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from haddock: C:\bayleya\eclipse\workspace\takusen\srchaddock -h --odir=doc Test/Haddock.lhs Cannot find documentation for: $named_block Okay, then I understand. My guess is (without looking at ghc code) that ghc just throws the literate comments away before lexing the file. This means that the Haddock comments won't be recognized. As you say, there is also an unlitter in Cabal. I don't remember if it is invoked when using Haddock 2, but if it is, it would solve this problem. Yes, against my better judgement the code in Cabal for haddock-2.x does not run cpp or unliting like it does for haddock-0.x. Instead it assumes that haddock-2.x will do all the cpp and unliting itself. Obviously this mean the special unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Working with HLint from Emacs
Does it also let you apply a suggestion automatically? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Staged evaluation, names?
On Thu, Jan 8, 2009 at 5:25 AM, wren ng thornton w...@freegeek.org wrote: The question for y'all is what should I call it? I've been calling the template-function qaf (for Compiled Applicative Form ;) and the type class with that function would be the only thing in the package, but I'm not sure where QAF.hs should be in the module hierarchy. Thoughts? Isn't Lift[1] already the right class for this? class Lift t where lift :: t - Q Exp [1] http://haskell.org/ghc/docs/latest/html/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3ALift ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threads with high CPU usage
Tried running the program with +RTS -Nn where n = 2 or more? that should use more OS threads On Sun, Dec 21, 2008 at 10:43 PM, Günther Schmidt red...@fedoms.com wrote: Hi, in an application of mine I start a long-running operation in a thread via forkIO so that the UI process doesn't get blocked. It just so happens, that the long-running process also takes the CPU to nearly 100% while it runs. During that time the run-time system does *not* switch back and forth between the UI-process and the long-running task, it seems that the UI process only gets woken up *after* the high CPU thread finishes completely. To the effect of course that it makes no difference at all to the UIs responsiveness whether I use forkIO or not. The long running process is pretty atomic, it's a single query to the database which takes up to a minute to complete so I don't see a chance to squeeze a mainIteration in there. What can I do? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ambiguous type variable woes
If you want to defer the choice of 's' you've to make it appear in the type
signature of test1, so you've to introduce an artificial parameter even if
we're interested only in its type. e.g.:
data Proxy (s :: * - * - *) -- useful because we can't have an argument
of type 's' directly, since it's higher-kinded,
-- and to document that we're using a
phantom argument
proxy :: Proxy s
proxy = undefined
test1 :: Stack s = Proxy s - Integer
test1 pr = first . p 2 . p 3 $ empty `asTypeOf` toStack pr
where toStack :: Proxy s - s a b
testTuple = test1 (proxy :: Proxy (,))
enabling LANGUAGE ScopedTypeVars you can rewrite test1 in a more direct
fashion:
test1 :: forall s. Stack s = Proxy s - Integer
test1 _ = fist . p 2 . p 3 $ (empty :: s () Void)
On Mon, Nov 24, 2008 at 5:09 AM, Jacques Carette [EMAIL PROTECTED]wrote:
I was trying to create a typeclass for an abstract Stack class, and ran
into some problems. The following 'works' fine:
{-# OPTIONS_GHC -XEmptyDataDecls -XFlexibleContexts
-fno-monomorphism-restriction #-}
module Stack where
data Void
class Stack s where
push_ :: s a r - b - s b (s a r)
empty :: s () Void
top :: s a (s b r) - (a, s b r)
first :: s a r - a
instance Stack (,) where
push_ s a = (a,s)
empty = ((),undefined::Void)
top = id
first = fst
p = flip push_
test0 = top . p 2 . p 3 $ empty
-- But the following doesn't - I get an Ambiguous type variable `s' in the
contraint `Stack s' arising from the use of `first':
test1 = first . p 2 . p 3 $ empty
-- sure, that makes sense, it somehow needs to know what flavour of Stack
to use even though (or perhaps because) the answer is independent of it.
-- So I listen to the probable fix and add a type signature:
test1 :: Stack (,) = Integer
-- This does not however help at all! The only way I have found of
'fixing' this requires annotating the code itself, which I most definitely
do not want to do because I specifically want the code to be polymorphic in
that way. But GHC 6.8.2 does not want to let me do this.
What are my options?
Jacques
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?
It's more natural to consider the cross product of no sets to be [[]] so
your crossr becomes:
crossr [] = [[]]
crossr (x:xs) = concat (map (\h -map (\t - h:t) (crossr tail)) hd)
which we can rewrite with list comprehensions for conciseness:
crossr [] = [[]]
crossr (x:xs) = [ a:as | a - x, as - crossr xs ]
then look at the definition of foldr:
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
and, considering (foldr f z) == crossr, you should derive the definition of
f and z.
On Mon, Nov 24, 2008 at 5:43 AM, Larry Evans [EMAIL PROTECTED]wrote:
On 11/23/08 13:52, Luke Palmer wrote:
2008/11/23 Larry Evans [EMAIL PROTECTED]:
http://www.muitovar.com/monad/moncow.xhtml#list
contains a cross function which calculates the cross product
of two lists. That attached does the same but then
used cross on 3 lists. Naturally, I thought use of
fold could generalize that to n lists; however,
I'm getting error:
You should try writing this yourself, it would be a good exercise. To
begin with, you can mimic the structure of cross in that tutorial, but
make it recursive. After you have a recursive version, you might try
switching to fold or foldM.
Thanks. The recursive method worked with:
-{--cross.hs--
crossr::[[a]] - [[a]]
crossr lls = case lls of
{ [] - []
; [hd]- map return hd
; hd:tail - concat (map (\h -map (\t - h:t) (crossr tail)) hd)
}
-}--cross.hs--
However, I'm not sure fold will work because fold (or rather foldr1)
from:
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#12
has signature:
(a-a-a)-[a]-a
and in the cross product case, a is [a1]; so, the signature would be
([a1]-[a1]-[a1]-[[a1]]-[a1]
but what's needed as the final result is [[a1]].
Am I missing something?
-Larry
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?
On Mon, Nov 24, 2008 at 7:40 AM, Andrea Vezzosi [EMAIL PROTECTED] wrote: It's more natural to consider the cross product of no sets to be [[]] so your crossr becomes: crossr [] = [[]] crossr (x:xs) = concat (map (\h -map (\t - h:t) (crossr tail)) hd Ops, hd and tail should be x and xs here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: problem with echo prompting in ghci (visible in emacs)
I get the same behaviour, and when I open ghci in xterm and press Ctrl-D it also echoes ^D before quitting, which is similar to the problem with haskell-mode which seems to don't like the echoing of ^J from ghci when one uses commands like C-u C-c C-t (which should copy the inferred type from the ghci buffer and insert it in the current file). I'm using the ghc package from archlinux testing repository, which is built with libedit 20080712_2.11. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] synchronous channels in STM
I'd rather say that STM is intended to be used just for building up transactions, not to model your whole process/thread, simply because in the latter case your process couldn't have any observable intermediate state, or put in another way, between any two transactions the information can only go in one direction. So, since synchronizing two processes needs bidirectional communication, you have to use more than one transaction. In the end you still write processes in IO, but communicate via transactions built in STM. It's a good thing to expose your primitives as STM when you can, so that users can build larger transactions on top of them, but a synchronous send is not a transaction from the start so there's no choice. 2008/10/9 roger peppe [EMAIL PROTECTED] On Thu, Oct 9, 2008 at 9:15 AM, Ryan Ingram [EMAIL PROTECTED] wrote: I don't think what you want is possible if both sides are in STM. Other authors have posted solutions where one side or the other of the transaction is in I/O, but wholly inside STM it's not possible. Thanks, that's what I thought, although I wasn't sure of it, being new to both Haskell and STM. Presumably this result means that it's not possible to implement any bounded-buffer-type interface within (rather than on top of) STM. Isn't that a rather serious restriction? cheers, rog. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] synchronous channels in STM
2008/10/9 Claus Reinke [EMAIL PROTECTED]
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv
primitives
on a channel that each block until the other side arrives to complete
the transaction.
Assuming that retry blocks until something changes, you could associate
a channel with a thread that encapsulates the transaction. Somewhat like
this?
You don't need an additional channel thread:
module SyncChan (SyncChan, send, recv, newSyncChan) where
import Control.Concurrent.STM
import Control.Monad
import Control.Concurrent
newtype SyncChan a = SC { unSC :: TVar (State a) }
data State a = Ready | Sent a | Received
newSyncChan :: STM (SyncChan a)
newSyncChan = SC `fmap` newTVar Ready
send :: SyncChan a - a - IO ()
send (SC chan) x = do
atomically $ unsafeSend chan x
atomically $ waitReceiver chan
recv :: SyncChan a - STM a
recv (SC chan) = do
s - readTVar chan
case s of
Sent s - writeTVar chan Received return s
_ - retry
unsafeSend chan x = do
s - readTVar chan
case s of
Ready - writeTVar chan (Sent x)
_- retry
waitReceiver chan = do
s - readTVar chan
case s of
Received - writeTVar chan Ready
_- retry
x | f = fmap f x
test b = do
(x,y) - atomically $ liftM2 (,) newSyncChan newSyncChan
forkIO $ join $ atomically $ -- since recv is in STM you can wait on
multiple channels at the same time
(recv x | print)
`mplus`
(recv y | print)
if b
then send x 'a'
else send y 1
as a bonus you can also try to send to the first available among multiple
channels:
(this formulation uses ExistentialQuantification but it's just a
convenience)
data Sending a = forall b. Sending (SyncChan b) b a
sendMulti :: [Sending a] - IO a
sendMulti [] = fail empty
sendMulti xs = do (m,r) - atomically $ msum $ map sending xs
atomically m
return r
sending :: Sending t - STM (STM (), t)
sending (Sending (SC chan) x k) = do
unsafeSend chan x
return (waitReceiver chan,k)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ambiguous types although 'asTypeOf'
As i understand it, the monomorphism restriction applies to constrained type variables, but c :: forall a. a, so it remains polymorphic and each of its uses can be instantiated to a different type. 2007/12/25, Henning Thielemann [EMAIL PROTECTED]: I thought I understand monomorphism restriction. But it seems, I don't. I have boilt down my problem to the following test. Don't try to make any sense of it, it is just the smallest code I could come up with. test :: (Integral a, RealFrac a) = a test = let c = undefined in asTypeOf (round c) c When compiling I get: Compiling StorableInstance ( src/StorableInstance.hs, interpreted ) src/StorableInstance.hs:38:17: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac a' arising from use of `round' at src/StorableInstance.hs:38:17-21 In the first argument of `asTypeOf', namely `(round c)' In the definition of `test1': test1 = let c = undefined in asTypeOf (round c) c ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XmlSerializer.deserialize?
As a side note i'd like to point out that introspectData has a problem with
constructors containing Strings because show (x::String) /= x:
data Foo = Foo { bar :: String } deriving (Typeable,Data)
introspectData (Foo quux) -- [(bar,\quux\)]
Those extras \ don't look very nice in the xml.. (the output of
introspectData is also wrong in the article's example )
you should probably use a modified gshow:
gshow' :: Data a = a - String
gshow' x = fromMaybe (gshow x) (cast x)
which is id for Strings.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] writer monad help
if by figure out you meant to do what tell does without using it, you should have written: foo = Writer ((),hello) that would have had the right type, using return you are doing something different. in the Writer monad return :: Monoid w = a - Writer w a so return ((),hello) :: Monoid w = Writer w ((),String) in fact in this case return a = Writer (a,mempty) so return ((),hello) == Writer (((),hello),mempty) in general you can't mess with the internals of a monad using return, it's only meant to lift a pure value in that monad. That's also a reason because tell is a typeclass method, you need to know how your specific monad data type work to implement it. full source: http://darcs.haskell.org/packages/mtl/Control/Monad/Writer/Lazy.hs 2007/5/18, iskaldur [EMAIL PROTECTED]: I'm trying to learn to use the Writer Monad, but I'm having trouble with the following very simple program: import Control.Monad.Writer foo :: Writer String Int foo = tell hello Basically, I was trying to figure out the 'tell' function, so I want foo to return ((), hello). But I get this error: Couldn't match `Int' against `()' Expected type: Writer String Int Inferred type: Writer String () In the application `tell hello' In the definition of `foo': foo = tell hello What am I supposed to do? Write my own version of tell for Writer String Int? How exactly do I do this? -- View this message in context: http://www.nabble.com/writer-monad-help-tf3777133.html#a10680445 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
