Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
On 08/01/2012 20:25, Brent Yorgey wrote: On Fri, Jan 06, 2012 at 10:51:58AM +, Steve Horne wrote: If I specify both extensions (-XMultiParamTypeClasses and -XFlexibleInstances) it seems to work, but needing two language extensions is a pretty strong hint that I'm doing it the wrong way. Not necessarily. These two extensions in particular (and especially the second) are quite uncontroversial. As it turns out, I don't need extensions at all, at least for walkableBinTree. Two answers pointed out how to handle that. I'm not yet entirely sure what will happen when I start adding more typeclasses (searchableBinTree etc) to the family - I've been distracted. Also - after reading those answers and trying the suggestions, I'm pretty sure I've done tutorials that covered this after all. I must have just left it too long before trying them out properly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]
On 12/28/11 10:14 AM, Brent Yorgey wrote: On Mon, Dec 26, 2011 at 12:32:13PM +0400, Eugene Kirpichov wrote: Actually it's not a bifunctor - it's a functor in one argument and contrafunctor in the other. Is there a name for such a structure? Bifunctor is usually used for such things as well. Data.Bifunctor only covers bifunctors which are covariant in both arguments. I'd just call them (contra(variant)) bifunctors. Or, more likely, I'd call them hom-(bi)functors since chances are the bifunctor supports the full structure of a category. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
On 08/01/2012 21:13, Brandon Allbery wrote: (Also, de facto I think it's already more or less been decided in favor of type families, just because functional dependencies are (a) a bit alien [being a glob of Prolog-style logic language imported into the middle of System Fc] and (b) [as I understand it] difficult to verify that the code in the compiler is handling all the potential corner cases right [mainly because of (a)]. Without meaning to express an opinion either way about an issue I don't understand... Isn't Haskell doing some prolog-ish things anyway? I thought the compiler must be doing unification to resolve type inference within expressions. It's not a simple expression evaluation problem (just evaluate the type rather than the value) because sometimes you know the return type but not (yet) the argument types - type information flows bottom-up and top-down through the same expression tree. I could easily be mistaken, though. Looking at the similar overload-resolution problem, Ada can resolve based on return types but C++ cannot. Ada needs unification or something similar to resolve overloading, whereas C++ just evaluates expressions for type instead of value. I can't now say for sure where I picked up the idea that Haskell needs unification to resolve type inference, but I've had some odd error messages which seem to confirm that belief - I assume because the mistake doesn't cause an immediate conflict, instead causing an indirect conflict somewhere else in the larger expression. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strict, lazy, non-strict, eager
On 12/28/11 6:47 AM, Thiago Negri wrote: I got a glimpse of understanding of what you are talking about after reading the wiki [1]. Still difficult to reason about the difference between lazy and non-strict without taking a look at the text. One way to keep them distinct is to recall that lazy is quite a bit more specific than non-strict. Let's take the wiki's definition: non-strict means evaluation from outside in (however problematic that may be). Now, just because we've specified this directionality of evaluation, that doesn't mean we've said everything we need to say about evaluation order. In particular, there are two common/obvious implementations of non-strict semantics: call-by-name, and call-by-need. In call-by-name evaluation, we just pass in the argument to functions as a literal expression. This is easy to reason about mathematically, however it has poor performance because it can cause duplication of effort. Namely, if a function uses its argument N times, then beta-reduction will create N copies of the argument, each of which will be evaluated (or not) separately. In call-by-need (aka lazy) evaluation, we don't just pass the expression in duplicating it if need be. Instead, we create a thunk and replace all references to the argument with references/pointers to the thunk. In this way, we can share the evaluation effort since we only have to evaluate/mutate the thunk once and the result can be shared across all use sites. In other words, in call-by-name beta-reduction is the familiar: (\x. a) $ b --- [x |- b] a where [_|-_]_ is literal substitution of expressions for variables in expressions. Whereas in call-by-need, beta-reduction is something like: (\x. a) $ b --- let x = b in a where let_=_in_ is a primitive construct for expressing shared substructure. Notably, in call-by-need the locus of evaluation shifts to a, so we evaluate under let_=_in_. The locus of evaluation only ever moves to b if indeed x is forced within a. In practice, GHC (and other Haskell compilers) are not lazy. That is, they do not exclusively use the call-by-need evaluation order. Instead, there is a hybridization of call-by-name, call-by-need, and call-by-value, the choice of which being based on the strictness analyzer and other optimization passes. The fact that GHC is allowed to do this can still call itself Haskell stems from the fact that the semantics of Haskell are defined merely as being non-strict, rather than being more specific. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strict, lazy, non-strict, eager
On 12/28/11 10:23 AM, Jon Fairbairn wrote: Thiago Negrievoh...@gmail.com writes: Lazy evaluation is one implementation of non-strict semantics, where the arguments are evaluated only when they are needed. I would say this: * non-strict semantics require that no argument is evaluated unless needed. I'm not sure that's quite right. As mentioned upthread, you can have eager non-strict languages. I think the more correct way to view it is that strict semantics require that non-termination of evaluating arguments entails non-termination of evaluating the application ---i.e., if [[ x ]] == _|_ then [[ f x ]] == _|_---, whereas non-strict semantics do not have this requirement. Thus, we're allowed to evaluate unused arguments, provided that doing so does not inhibit us from giving the proper result for evaluating the application. Some possibilities would be: to fork off a thread for evaluation of each subterm, or to eagerly evaluate arguments optimistically but then fall back to a non-strict evaluation model if the argument takes too long to finish, or to restrict ourselves to a total language and then use any strict semantics we like (since strict and non-strict coincide if there is no bottom),... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are all monads functions?
On 12/31/11 8:18 AM, Yves Parès wrote: Thanks for the explanation on free monads, it's interesting. But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad: -- The plain Maybe type data Maybe a = Just a | Nothing -- The MaybeMonad newtype MaybeMonad a = MM ( () - Maybe a ) That's what using Maybe as a monad semantically means, doesn't it? Well, to take the category-theoretic perspective, a value or element of X is simply defined to be any morphism from the terminal object into X. Thus, saying x \in X or x :: X is just another way to say x : 1 - X. The unit type isn't quite terminal because it has two values, but it's close enough to get the idea. If unit truly had only one value, then ()-Y is at least (isomorphic to) a subobject of Y, and almost surely isomorphic to (all of) Y. All of this is just by the definition of what a terminal object is; nothing about monads anywhere. Also note that (X -) forms a monad for any X. But that's a separate issue. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strict, lazy, non-strict, eager
wren ng thornton w...@freegeek.org writes: On 12/28/11 10:23 AM, Jon Fairbairn wrote: Thiago Negrievoh...@gmail.com writes: Lazy evaluation is one implementation of non-strict semantics, where the arguments are evaluated only when they are needed. I would say this: * non-strict semantics require that no argument is evaluated unless needed. I'm not sure that's quite right. I’m sure it’s not right (as was pointed out a while ago). I was in too much of a hurry to get to the next bit, namely giving a description of the difference between non-strict and lazy. Perhaps what I should have said to be almost as succinct but this time accurate is “non-strict semantics requires that the evaluation strategy terminate if there is any evaluation strategy that terminates”? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
Hi, On Mon, Jan 09 2012 at 10:37 +0100, Steve Horne wrote: On 08/01/2012 21:13, Brandon Allbery wrote: (Also, de facto I think it's already more or less been decided in favor of type families, just because functional dependencies are (a) a bit alien [being a glob of Prolog-style logic language imported into the middle of System Fc] and (b) [as I understand it] difficult to verify that the code in the compiler is handling all the potential corner cases right [mainly because of (a)]. Isn't Haskell doing some prolog-ish things anyway? I thought the compiler must be doing unification to resolve type inference within expressions. Even quite basic type reconstruction (e.g. for ML) needs unification, see e.g. Pierce TaPL chapter 22. The algorithm is rather easy to understand and implement. Based on that, I wouldn't think using /some kind of unification/ in the compilation process qualifies as being particularly prolog-ish. I suppose ``...importing a Prolog-style logic language...'' would mean to allow a significantly more powerful (and explicit) way of expressing constraints in the type system than before. I believe Brandon Allbery, when he says that this is difficult. Best regards Lu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD studentship in Nottingham
Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 If you are interested in applying yourself, please drop me a note by email. If you know of any good candidates who may be interested in applying, or there is a local mailing list for advertising such things, I'd be much obliged if you could pass on the above link. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiments in Haskell Packaging
I don’t have any problem with installing the tools into user-land – this will be true of all of the components in the justhub distro – provided you start with the source code. Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. I have looked into it -- unless we can unpack a bindist as part of the post-install step, it doesn't look practical. I have yet to be convinced that the RPM route make sense for the restrictive situation that Sanket outlines and I am trying to keep an open mind. I don't want to distribute sources either -- I think the solution will involve bindists. What a piece of work is a GHC bindist! Chris -Original Message- From: juhpeter...@gmail.com [mailto:juhpeter...@gmail.com] On Behalf Of Jens Petersen Sent: 08 January 2012 08:03 To: Chris Dornan Subject: Re: [Haskell-cafe] Experiments in Haskell Packaging I don’t have any problem with installing the tools into user-land – this will be true of all of the components in the justhub distro – provided you start with the source code. Long ago the Fedora Haskell project's rpm packages were relocatable for this reason. So it may still be possible and not that hard to do. Jens ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad-control rant
Hello Mikhail, (Apologies for reviving a two month old thread). Have you put some thought into whether or not these extra classes generalize in a way that is not /quite/ as general as MonadBaseControl (so as to give you the power you need) but still allow you to implement the functionality you are looking for? I'm not sure but it seems something along the lines of unwind-protect ala Scheme might be sufficient. Edward Excerpts from Mikhail Vorozhtsov's message of Mon Nov 14 01:25:34 -0500 2011: On 11/14/2011 06:55 AM, Bas van Dijk wrote: Hi Mikhail, your type class: class MonadAbort e μ ⇒ MonadRecover e μ | μ → e where recover ∷ μ α → (e → μ α) → μ α looks a lot like the MonadCatchIO type class from MonadCatchIO-transformers: class MonadIO m = MonadCatchIO m where catch :: E.Exception e = m a - (e - m a) - m a I haven't looked at your code in detail but are you sure your continuation based AIO monad doesn't suffer from the same unexpected behavior as the ContT monad transformer with regard to catching and handling exceptions? Yes, I'm sure. The reason why it works is because finally/bracket/etc are not implemented on top of 'recover' (i.e. they don't assume that throwing an exception is the only reason control can escape). The following class takes care of it: class (Applicative μ, Monad μ) ⇒ MonadFinally μ where finally' ∷ μ α → (Maybe α → μ β) → μ (α, β) finally ∷ μ α → μ β → μ α finally m = fmap fst . finally' m . const Finalizers have type 'Maybe α → μ β' so we can (a) Thread transformer side effects properly: instance MonadFinally μ ⇒ MonadFinally (L.StateT s μ) where finally' m f = L.StateT $ \s → do ~(~(mr, _), ~(fr, s'')) ← finally' (L.runStateT m s) $ \mbr → do let ~(a, s') = case mbr of Just ~(x, t) → (Just x, t) Nothing → (Nothing, s) L.runStateT (f a) s' return ((mr, fr), s'') (b) Detect that control escaped computation before producing a result (finalizer will be called with 'Nothing' in that case). instance (MonadFinally μ, Error e) ⇒ MonadFinally (ErrorT e μ) where finally' m f = ErrorT $ do ~(mr, fr) ← finally' (runErrorT m) $ \mbr → runErrorT $ f $ case mbr of Just (Right a) → Just a _ → Nothing return $ (,) $ mr * fr That of course does not mean that I can use 'finally' and friends with ContT, but I can use them with monads which are carefully /implemented/ on top of ContT but do not expose it's full power to the users. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically
Tom, thank you very much for the ThreadScope feedback. Anything new? Anybody? We are close to a new release, so that's the last call for bug reports before the release. Stay tuned. :) On Fri, Dec 16, 2011 at 11:34, Tom Thorne thomas.thorn...@gmail.com wrote: Hi, I can't remember if it was threadscope that crashed or the RTS, since I was also having segfaults in the RTS because of this bug, that is fixed in 7.2.2: http://hackage.haskell.org/trac/ghc/ticket/5552 I successfully used threadscope by running my code for fewer iterations to produce a smaller log, and it was helpful to make sure I was dividing work equally between the threads. I think I still have the log file that was about 1.8GB so I will try running threadscope on it and see what happens. The performance problems I was having turned out to be fixed completely by changing the GC options passed to the RTS. thanks! Tom On Friday, 16 December 2011 at 09:20, Mikolaj Konarski wrote: On Mon, Oct 10, 2011 at 15:55, Tom Thorne thomas.thorn...@gmail.com wrote: Yes I will try to run threadscope on it, I tried it before and the event log output produced about 1.8GB, and then crashed. Hi Tom, I'm one of the TS/ghc-events hackers and I'd like to learn more, fix it or at least put it on the TS/ghc-events issue tracker (http://trac.haskell.org/ThreadScope). Could you help me reproduce the problem? Did ThreadScope crash or RTS? Which versions? Was it 1.8GB of the log file or RAM? Did you succeed eventually? Any other TS feedback? Thank you, Mikolaj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD studentship in Nottingham
Dear all, I am currently advertising a PhD Studentship in Functional Programming at the University of Nottingham in the UK: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088 If you are interested in applying yourself, please drop me a note by email. If you know of any good candidates who may be interested in applying, or there is a local mailing list for advertising such things, I'd be much obliged if you could pass on the above link. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically
On Mon, 9 Jan 2012 18:22:57 +0100, Mikolaj Konarski mikolaj.konar...@gmail.com wrote: Tom, thank you very much for the ThreadScope feedback. Anything new? Anybody? We are close to a new release, so that's the last call for bug reports before the release. Stay tuned. :) As it turns out, I ran into a similar issue with a concurrent Gibbs sampling implmentation I've been working on. Increasing -H fixed the regression, as expected. I'd be happy to provide data if someone was interested. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
