Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module

[Andrea Vezzosi]

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: [Haskell-cafe] SYB with class: Bug in Derive.hs module

[Andrea Vezzosi]

On Mon, Sep 3, 2012 at 2:53 PM, Roman Cheplyaka  wrote:
> * Andrea Vezzosi  [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: [Haskell-cafe] SYB with class: Bug in Derive.hs module

[Andrea Vezzosi]

On Mon, Sep 3, 2012 at 12:00 PM, Roman Cheplyaka  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] Set monad

[Andrea Vezzosi]

On Sun, Jan 9, 2011 at 7:45 AM, Sebastian Fischer  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: [Haskell-cafe] Speed of Error handling with Continuations vs. Eithers

[Andrea Vezzosi]

On Thu, May 13, 2010 at 8:13 PM, wren ng thornton  wrote:
> Andrea Vezzosi wrote:
>>
>> On Thu, May 13, 2010 at 10:51 AM, wren ng thornton 
>> 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

[Andrea Vezzosi]

On Thu, May 13, 2010 at 10:51 AM, wren ng thornton  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

[Andrea Vezzosi]

On Wed, May 12, 2010 at 7:50 AM, wren ng thornton  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 <> very, very mysteriously

[Andrea Vezzosi]

On Mon, Dec 7, 2009 at 3:38 PM, David Fox  wrote:
> On Sat, Dec 5, 2009 at 2:38 AM, Andrea Vezzosi  wrote:
>> On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw  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 <> very, very mysteriously

[Andrea Vezzosi]

On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw  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: [Haskell-cafe] Re: GHC: compile using multiple cores?

[Andrea Vezzosi]

The main bottleneck right now is that each ghc process has to read the
package.conf, which afaiu is done with Read and it's awfully slow,
especially if you have many packages installed.
I've started seeing total time improvements when approaching ~300% CPU
usage and only the extralibs installed.

On Thu, Apr 9, 2009 at 5:51 PM, Neil Mitchell  wrote:
>> Not with cabal, with GHC, yes: assuming you have enough modules. Use ghc
>> -M to dump a makefile, and then make -j20 (or whatever you have)
>
> There is a performance penalty to running ghc on separate files vs
> --make. If your number of core's is limited --make may be better. I'd
> love someone to figure out what the cross over point is :-)
>
> As a related question, how does GHC implement -j3? For my programs, if
> I want to run in parallel, I have to type +RTS -N3. Can I use the same
> trick as GHC?
>
> Thanks
>
> Neil
> ___
> 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] cabal haddock and Paths_Xxx

[Andrea Vezzosi]

Which version of Cabal are you using?
It should be fixed with Cabal-1.6.0.2, check cabal --version to make
sure it's not using an older one.

On Mon, Apr 6, 2009 at 8:32 PM, Martijn van Steenbergen
 wrote:
> Hello,
>
> cabal generates a Paths_Xxx file for me which I import and use, but cabal
> haddock doesn't seem to like it much.
>
> If I don't specify the generated module at all in my cabal file, cabal
> haddock generates visible documentation for the module, which is not what I
> want: the module should stay internal.
>
> If I specify it in either Exposed-Modules or Other-Modules, 'cabal
> configure; cabal haddock' fails with:
>
>> cabal: can't find source for Paths_Xxx in ., dist/build/autogen
>
> While 'cabal configure; cabal build; cabal haddock' fails with:
>
>> cabal: can't find source for module Paths_Xxx
>
> Can I have the best of both, i.e. generate docs without problems and use the
> generated module?
>
> Thanks,
>
> Martijn.
> ___
> 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: Completely confused by cabal

[Andrea Vezzosi]

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] Re: Completely confused by cabal

[Andrea Vezzosi]

On Sun, Mar 22, 2009 at 12:51 PM, Colin Paul Adams
 wrote:
>> "Achim" == Achim Schneider  writes:
>
>    Achim> Colin Paul Adams  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] do you have to use fix with forkio?

[Andrea Vezzosi]

2009/3/6 Daryoush Mehrtash :
> 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 
>>
>> On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave  wrote:
>>>
>>> Quoth Jonathan Cast :
>>>
>>> > 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

[Andrea Vezzosi]

2009/2/22 Luke Palmer :
> On Sun, Feb 22, 2009 at 8:15 AM, John Meacham  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

[Andrea Vezzosi]

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  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:\Temp>runghc 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?

[Andrea Vezzosi]

On Tue, Feb 17, 2009 at 11:50 PM, Achim Schneider  wrote:
> Martin Huschenbett  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
> 
>
>
> [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

[Andrea Vezzosi]

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
 wrote:
> On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:
>> 2009/2/6 Alistair Bayley :
>> >>> [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\src>haddock -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

[Andrea Vezzosi]

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?

[Andrea Vezzosi]

On Thu, Jan 8, 2009 at 5:25 AM, wren ng thornton  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

[Andrea Vezzosi]

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  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

[Andrea Vezzosi]

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?

[Andrea Vezzosi]

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: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?

[Andrea Vezzosi]

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] synchronous channels in STM

[Andrea Vezzosi]

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

[Andrea Vezzosi]

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'

[Andrea Vezzosi]

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?

[Andrea Vezzosi]

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

[Andrea Vezzosi]

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