Re: [Haskell-cafe] The maximum/minimum asymmetry
On 4 September 2011 21:44, Mario Blažević blama...@acanac.net wrote: I was recently surprised to discover that the maximum and maximumBy functions always return the *last* maximum, while minimum and minimumBy return the *first* minimum in the list. The following GHCi session demonstrates this: $ ghci GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :module +Data.List Data.Ord Prelude Data.List Data.Ord let list = [(1, 'B'), (1, 'A')] Prelude Data.List Data.Ord maximumBy (comparing fst) list (1,'A') Prelude Data.List Data.Ord minimumBy (comparing fst) list (1,'B') I would normally consider this kind of gratuitous asymmetry a bug, but seeing that these functions' implementations have been specified in the Haskell 98 Library Report, I guess they are now a permanent feature of the language. Can anybody explain the reason for this behaviour? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe The asymmetry is a result of EQ and LT being treated as equivalent in both the minBy and maxBy helper functions in the report's definition of the two functions, which has opposite effects for minimumBy and maximumBy. Since the documentation doesn't specify a behavior for equal values, I could guess that it was just an oversight or that it was considered unimportant. But maybe someone more knowledgeable will correct me. Alexander Dunlap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lens with merge (Semigroup)
A regular Lens can be represented as follows: data CoState a = CoState (a - b) a newtype Lens a b = Lens (a - CoState b a) I once read about a lens representation that permits a general merge operation. I forget where I read it -- I think it was #haskell IRC. However, as I recall, perhaps incorrectly, the merge operation involves a Semigroup[1] and helps to overcome the fact that Lens is not an Arrow and so does not have a () operation. I am interested to know what this Lens operation is and the associated merge operation. [1] -- Approximate data SemigroupT f a = SemigroupT (a - a - f a) -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 02:38, Sebastian Fischer fisc...@nii.ac.jp wrote: These are important questions. I think there is a trade-off between supporting many cases and having a simple desugaring. We should find a sweet-spot where the desugaring is reasonably simple and covers most idiomatic cases. I have proposed a desugaring (in executable form) at https://gist.github.com/1194308. My desugaring aims for a slightly different design that does not try to detect return and instead treats the use of *, * and liftA2 purely as an optimisation - so any computation using do still generates a Monad constraint, but it may be desugared in a more efficient way than it is currently by using the Applicative combinators. (If you do want to support the type checker only generating requests for an Applicative constraint you could just insist that user code writes pure instead of return, in which case this would be quite easy to implement) There are still some interesting cases in my proposal. For example, if you have my second example: x - computation1 y - computation2 z - computation3 y computation4 x You might reasonably reassociate computation2 and computation3 together and desugar this to: liftA2 computation1 (computation2 = \y - computation3 y) = \(x, _z) - computation4 x But currently I desugar to: liftA2 computation1 computation2 = \(x, y) - computation3 y * computation4 x It wouldn't be too hard (and perhaps a nice exercise) to modify the desugaring to do this reassocation. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 08:35, Max Bolingbroke batterseapo...@hotmail.com wrote: (If you do want to support the type checker only generating requests for an Applicative constraint you could just insist that user code writes pure instead of return, in which case this would be quite easy to implement) I take back this parenthetical remark. Using pure instead of return only solves the most boring 1/2 of the problem :-) Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: do computation1 computation2 computation3 Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The maximum/minimum asymmetry
On Monday 05 September 2011, 08:35:30, Alexander Dunlap wrote: On 4 September 2011 21:44, Mario Blažević blama...@acanac.net wrote: I was recently surprised to discover that the maximum and maximumBy functions always return the *last* maximum, while minimum and minimumBy return the *first* minimum in the list. The following GHCi session demonstrates this: $ ghci GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :module +Data.List Data.Ord Prelude Data.List Data.Ord let list = [(1, 'B'), (1, 'A')] Prelude Data.List Data.Ord maximumBy (comparing fst) list (1,'A') Prelude Data.List Data.Ord minimumBy (comparing fst) list (1,'B') I would normally consider this kind of gratuitous asymmetry a bug, but seeing that these functions' implementations have been specified in the Haskell 98 Library Report, I guess they are now a permanent feature of the language. Can anybody explain the reason for this behaviour? The asymmetry is a result of EQ and LT being treated as equivalent in both the minBy and maxBy helper functions in the report's definition of the two functions, which has opposite effects for minimumBy and maximumBy. Since the documentation doesn't specify a behavior for equal values, I could guess that it was just an oversight or that it was considered unimportant. But maybe someone more knowledgeable will correct me. Alexander Dunlap The default methods for min and max already have this: max x y = if x = y then y else x min x y = if x = y then x else y I think the reason for this is that if you have (a, b) = (min x y, max x y), you'll get both values even if they compare equal (and not everybody thinks that if two values compare equal, they shouldn't be distinguishable by any other means, so it might matter). Probably, the behaviour of minimum[By] and maximum[By] is intentional as an extension of this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Idiomatic usage of the fixpoint library
On Sun, Sep 4, 2011 at 13:03, Roman Cheplyaka wrote: * Sean Leather [2011-09-04 12:48:38+0200] On Sun, Sep 4, 2011 at 12:31, Roman Cheplyaka wrote: I'm looking for an example of idiomatic usage of the fixpoint library[1]. [1]: http://hackage.haskell.org/package/fixpoint-0.1.1 I'm not sure if this counts for idiomatic usage, but you can check out our approach to incrementalization. http://people.cs.uu.nl/andres/Incrementalization/ Yeah, it has more or less the same problems as my code above. You essentially defined your tree twice (Tree and F (Tree)). For such a simple type it's fine, but if it was an AST with a few dozens of constructors, such approach would be unacceptable. True. Technically, one doesn't need Expr or Tree, right? But if you prefer to define your datatype that way, that's usually where I turn to code generation, possibly using Template Haskell, Data.Derive, or something else. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jp wrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Idiomatic usage of the fixpoint library
Roman Cheplyaka wrote:
{-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances,
FlexibleInstances #-}
import Data.Fixpoint
newtype Expr = Expr { unExpr :: Pre Expr Expr }
instance Functor (Pre Expr) = Fixpoint Expr where
data Pre Expr a
= Add a a
| Const Int
project = unExpr
inject = Expr
instance Functor (Pre Expr) where
fmap f (Const x) = Const x
fmap f (Add x1 x2) = Add (f x1) (f x2)
eval = cata eval' where
eval' (Const x) = x
eval' (Add x1 x2) = x1 + x2
There are some issues with this code, compared to simply using
newtype Fix f = In { out :: f (Fix f) }
to build an Expr.
1. Since 'Pre' is a data (not type) family, we cannot simply make use of
a functor defined elsewhere. We need to define the functor inside the
instance declaration (or at least wrap an existing functor).
Yes, it would be nicer if it was a type family. There is a single reason
why this isn't the case but I find that reason pretty compelling: you
couldn't type hylo if it was.
2. I wasn't able to derive the Functor instance, getting an error
Derived instance `Functor (Pre Expr)'
requires illegal partial application of data type family Pre
In the data type instance declaration for `Pre'
That's really a GHC problem. There is no reason why it shouldn't be able
to do this.
3. Having to use UndecidableInstances makes me feel a bit uncomfortable.
You don't need UndecidableInstances. Just get rid of the Functor (Pre
Expr) constraint on the Fixpoint Expr instance, it's doesn't do anything
anyway.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 13:41, Sebastian Fischer fisc...@nii.ac.jp wrote: Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c I find (a b) confusing. The intended semantics seem to be effect a, then effect b, return result of a. That doesn't seem intuitive to me because it contradicts with the effect ordering of (=) which reverses the effect ordering of (=). We already have (*) and (*) for left-to-right effect ordering and pointed result selection. I understand that () = (*) apart from the Monad constraint, but I would prefer not to have () = (*). The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Package descriptions on hackage
Dear hackage package authors, this is a short message from your distribution package creators: Please, if possible, write good, not too short descriptions, and also keep them up to date. Of course, users browsing hackage will benefit as well. Keep in mind that the users do not know what other packages this relates to. So if the package is part of a larger set of corresponding packages, include a general blob and then explain this particular packages. This is especially true for packages that contain the base types for a suite of packages. Also think about all the possible keywords that someone might enter in a search engine when looking for something like your package, and ideally explain how your library relates to these keywords so that the user can estimate whether it useful for him even before reading the API. Here a few negative examples, not to expose particular authors, but selected because they were the most resent that the Debian Haskell Team had packaged. = The http-enumerator package This package uses attoparsec for parsing the actual contents of the HTTP connection. The only gotcha is the withHttpEnumerator function, otherwise should do exactly what you expect. (A list of supported features would be great, maybe a short note what enumerator means. Also, the second sentence is incomprehensible to me and the latest version does not contain a withHttpEnumerator function any more) = The representable-functors package Representable functors (Clearly not helpful. Here is what Iulian came up for for the Debian package, from the individual module documentation, but I still think the author could do better This package provides a generalized Store comonad, parameterized by a Representable functor (the representation of that functor serves as the index of the store) and a generalized State monad, parameterized by a Representable functor (the representation of that functor serves as the state). Representable functors on Hask all monads, being isomorphic to a reader monad. Representable contravariant endofunctors over the category of Haskell types are isomorphic to (_ - r) and resemble mappings to a fixed range. Representable endofunctors over the category of Haskell types are isomorphic to the reader monad and so inherit a very large number of properties for free.) = The data-lens package Haskell 98 Lenses (Also not helpful. And probably a very useful package! Iulian wrote „A lense is a composable notion of a purely functional field accessor.“ which is still quite short, but explains the use of the package much better) = The algebra package Constructive abstract algebra (Seems to be the “main” package of a series of packages. Yet another reason for having a good description. Here a suggestion, again by Iulian: “This package provides algebraic structures, such as groups, fields, rings, modules. It also provides bands, also known as idempotent semigroups (band is a semigroup where every element is equal to its own square), coalgebras, semirings (rigs), idempotent semirings, also known as dioids.“) = I know that most people have better things to do than to write API documentation, so it is not unexpected that, after having written the API documentation after all, they don’t spend too much time on the description. But think about it: It is the first thing possible users are going to see from your package. So if you want to attract users, do take your time to write a comprehensive and comprehensible description. Thanks, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The maximum/minimum asymmetry
On 11-09-05 12:44 AM, Mario Blažević wrote: I was recently surprised to discover that the maximum and maximumBy functions always return the *last* maximum, while minimum and minimumBy return the *first* minimum in the list. Though not beautifully symmetric, it's beautifully dual! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The maximum/minimum asymmetry
This way these laws hold for non-empty lists: maximumBy f xs = last (sortBy f xs) minimumBy f xs = head (sortBy f xs) Sjoerd Visscher On Sep 5, 2011, at 6:44 AM, Mario Blažević wrote: I was recently surprised to discover that the maximum and maximumBy functions always return the *last* maximum, while minimum and minimumBy return the *first* minimum in the list. The following GHCi session demonstrates this: $ ghci GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :module +Data.List Data.Ord Prelude Data.List Data.Ord let list = [(1, 'B'), (1, 'A')] Prelude Data.List Data.Ord maximumBy (comparing fst) list (1,'A') Prelude Data.List Data.Ord minimumBy (comparing fst) list (1,'B') I would normally consider this kind of gratuitous asymmetry a bug, but seeing that these functions' implementations have been specified in the Haskell 98 Library Report, I guess they are now a permanent feature of the language. Can anybody explain the reason for this behaviour? ___ 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] Smarter do notation
On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling nomin...@googlemail.comwrote: a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. liftA2 is defined via one-at-a-time application and cannot be redefined because it is no method of Applicative. Do you remember more details? I find (a b) confusing. The intended semantics seem to be effect a, then effect b, return result of a. Sorry, I didn't know that doesn't exist. I meant an operator with the meaning of * . Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Smarter do notation
-- Forwarded message -- From: Alberto G. Corona agocor...@gmail.com Date: 2011/9/5 Subject: Re: [Haskell-cafe] Smarter do notation To: Sebastian Fischer fisc...@nii.ac.jp Cc: Max Bolingbroke batterseapo...@hotmail.com, haskell-cafe@haskell.org The problem in the parallel distribution of monadic computations that may have been Applicative seems to be the operator But if Monad is defined as a subclass of applicative: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal then can be defined as () = (*) and parallelization should be pòssible ? Alberto 2011/9/5 Sebastian Fischer fisc...@nii.ac.jp Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ 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] Smarter do notation
The problem in the parallel distribution of monadic computations that may have been Applicative seems to be the operator But if Monad is defined as a subclass of applicative: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal then can be defined as () = (*) and parallelization should be pòssible ? Alberto 2011/9/5 Sebastian Fischer fisc...@nii.ac.jp Hi again, I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation: a = \p - return b -- (\p - b) $ a a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b a = \p - f $ b -- 'free p' and 'free f' disjoint -- f $ (a = \p - b) a = \p - b * c -- 'free p' and 'free c' disjoint -- (a = \p - b) * c a = \p - b = \q - c -- 'free p' and 'free b' disjoint -- liftA2 (,) a b = \(p,q) - c a = \p - b c -- 'free p' and 'free b' disjoint -- (a b) = \p - c The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'. If return, , and are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return. Sebastian On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Max, thanks for you proposal! Using the Applicative methods to optimise do desugaring is still possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method: Is this still true, once Monad is a subclass of Applicative which defines return? I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then.. Sebastian ___ 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] The maximum/minimum asymmetry
On 11-09-05 10:42 AM, Sjoerd Visscher wrote: This way these laws hold for non-empty lists: maximumBy f xs = last (sortBy f xs) minimumBy f xs = head (sortBy f xs) That's not a bad justification for the way implementation works, even if it's not the original reason behind it. I think these laws should be added to the Haddock documentation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC/Cabal on AFS
I have the Haskell Platform (and my home directory with my cabal-installed packages) installed on an AFS (a network filesystem) volume and have been noticing a strange issue. Whenever I install a package using cabal-install and it gets to a phase of the build where it needs to load a bunch of packages, the build fails without a useful error. Example: cabal-dev install yesod Resolving dependencies... Configuring yesod-core-0.9.1.1... Preprocessing library yesod-core-0.9.1.1... Preprocessing test suites for yesod-core-0.9.1.1... Building yesod-core-0.9.1.1... [ 1 of 15] Compiling Yesod.Internal.Session ( Yesod/Internal/Session.hs, dist/build/Yesod/Internal/Session.o ) [ 2 of 15] Compiling Paths_yesod_core (dist/build/autogen/Paths_yesod_core.hs, dist/build/Paths_yesod_core.o) [ 3 of 15] Compiling Yesod.Logger (Yesod/Logger.hs,dist/build/Yesod/Logger.o ) [ 4 of 15] Compiling Yesod.Internal.RouteParsing(Yesod/Internal/RouteParsing.hs,dist/build/Yesod/Internal/RouteParsing.o) [ 5 of 15] Compiling Yesod.Internal (Yesod/Internal.hs,dist/build/Yesod/Internal.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.0.5 ... cabal: Error: some packages failed to install: yesod-0.9.1.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-auth-0.7.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-core-0.9.1.1 failed during the building phase. The exception was: ExitFailure 7 yesod-form-0.3.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-json-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-persistent-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. If I keep re-running it, it will eventually succeed. It also always makes forward progress (the next attempt will get past text and a few more packages). It seems to be related to the state of the AFS cache; if all of the required packages are in the local AFS cache it usually just works. If the cache has just been flushed (due to other FS operations), this failure pretty much always shows up. Has anyone else experienced anything like this? Alternatively, does anyone have ideas on getting a more useful error message/tracking it down? I didn't see any relevant bugs filed yet, but I wanted to get more information before adding a report. pgp9w1Uo9NUnD.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC/Cabal on AFS
Yep We get this as well - as you say, once it is in the cache it works fine Neil On 5 Sep 2011, at 18:06, Tristan Ravitch wrote: I have the Haskell Platform (and my home directory with my cabal-installed packages) installed on an AFS (a network filesystem) volume and have been noticing a strange issue. Whenever I install a package using cabal-install and it gets to a phase of the build where it needs to load a bunch of packages, the build fails without a useful error. Example: cabal-dev install yesod Resolving dependencies... Configuring yesod-core-0.9.1.1... Preprocessing library yesod-core-0.9.1.1... Preprocessing test suites for yesod-core-0.9.1.1... Building yesod-core-0.9.1.1... [ 1 of 15] Compiling Yesod.Internal.Session ( Yesod/Internal/Session.hs, dist/build/Yesod/Internal/Session.o ) [ 2 of 15] Compiling Paths_yesod_core (dist/build/autogen/Paths_yesod_core.hs, dist/build/Paths_yesod_core.o) [ 3 of 15] Compiling Yesod.Logger (Yesod/Logger.hs,dist/build/Yesod/Logger.o ) [ 4 of 15] Compiling Yesod.Internal.RouteParsing(Yesod/Internal/RouteParsing.hs,dist/build/Yesod/Internal/RouteParsing.o) [ 5 of 15] Compiling Yesod.Internal (Yesod/Internal.hs,dist/build/Yesod/Internal.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.0.5 ... cabal: Error: some packages failed to install: yesod-0.9.1.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-auth-0.7.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-core-0.9.1.1 failed during the building phase. The exception was: ExitFailure 7 yesod-form-0.3.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-json-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-persistent-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. If I keep re-running it, it will eventually succeed. It also always makes forward progress (the next attempt will get past text and a few more packages). It seems to be related to the state of the AFS cache; if all of the required packages are in the local AFS cache it usually just works. If the cache has just been flushed (due to other FS operations), this failure pretty much always shows up. Has anyone else experienced anything like this? Alternatively, does anyone have ideas on getting a more useful error message/tracking it down? I didn't see any relevant bugs filed yet, but I wanted to get more information before adding a report. ___ 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] Solving the configuration problem with parametrized modules
Hi Cafe, this is an idea that has been floating in my head for a while, and I’m wondering about its feasibility and, if feasible, complexity (in the range from „trivial“ over “blog post” over “paper” to “thesis”). Application authors in Haskell often face the problem of run-time constants, e.g. values that are expected to be determined once during program start and then stay fixed for the remainder of the run. Good examples are user configuration values (--verbose, certain paths, debugging level, etc.). Usually in Haskell, you’d determine them in the main function and then pass them in an argument to all functions needing them, or you wrap that in a monad. This works and has the advantage of being explicit. One can locally change the value when passing it to another function – this can be a good thing (more powerful) or a bad thing (if the programmer had runtime-constant behavior in mind, an invariant not enforced by the type system or the compiler). The big downside is the verbosity of the approach: A lot of parameters need to be passed, and if one such value is suddenly required in a function where it was not before, this function’s signature and all functions using it have to be modified. Also, I expect that the explicit passing causes a small performance penalty. A less idiomatic approach would be something like this: == module M confRef = unsafePerformIO $ newIORef (error not set yet) conf = unsafePerformIO $ readIORef confRef f = ... conf ... == import M main = do ... writeIORef confRef theValue ... f ... == This has the nice effect that the programmer can use conf as if it is a proper constant value. It could also be quicker, as nothing needs to be passed on the stack. But besides the subtle issues about inlining, this has the big issue of glaring unsafeness: There is no guarantee that confRef is actually set before conf is evaluated, and any code can easily change the confRef anywhere during the runtime. I’d like to propose (on the theoretical level for now, don’t worry) an extension to the language to support _parametrized modules_, which work internally similar to the example above, but with the compiler statically ensuring correctness, where correctness means * The parameter is not evaluated before it is set. * It is set at most once. Rouch syntax sketch: == module M parameters (conf1, conf2) f = ... conf ... == import M main = do ... M.setParameters someVal1 someVal2 ... f ... == where setParameters is a symbol generated by the compiler. The tricky part is, of course, ensuring the correctness. For example while main = do M.setParameters 1 2 ...f... should be easy to check, how about main = do id $ M.setParameters 1 2 ...f... or even main = do bool - someIOAction guard bool $ M.setParameters 1 2 ...f... ? I envision a ghc extensions that would allow to one to hook into the type checker and attach bits of information (here: „uses conf“ and „initizalizes M“) to the types, and also check certain conditions (e.g. a = b is invalid if a and b both have „initializes M“ attached). If this extension was loaded when id was compiled, it should probably accept the second case, but when no such information is available, or in the third case, reject the code. A framework for such attached bits would surely enable more extensions that statically check some condition that is hard or unwieldy to express in the type system. I have more ideas in that direction, but before I start brabbling, maybe I should first wait for your reactions. Do you think this could be useful (from a user point of view)? Has this idea maybe already been proposed? Thanks, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solving the configuration problem with parametrized modules
On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner m...@joachim-breitner.de wrote: Do you think this could be useful (from a user point of view)? Has this idea maybe already been proposed? How does it compare with Oleg's typeclass approach? http://okmij.org/ftp/Haskell/types.html#Prepose -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solving the configuration problem with parametrized modules
Hi, Am Montag, den 05.09.2011, 14:35 -0400 schrieb Gwern Branwen: On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner m...@joachim-breitner.de wrote: Do you think this could be useful (from a user point of view)? Has this idea maybe already been proposed? How does it compare with Oleg's typeclass approach? http://okmij.org/ftp/Haskell/types.html#Prepose the big difference is that Oleg’s approach exploits the existing type system. This is elegant, as it does not need additional support by the compiler. The “disadvantage” is that you have to still have to adjust type signatures (quotes because there is some value in explicitly stating the use of parameters), and it might (possibly) interfere with other fancy usages of of the type system. My proposal adds a second layer of “type” checking, i.e. the terms have their types as before (and all guarantees by the type system prevail), and a second round of inference and checking ensures the additional property of properly setting and using the module¹ parameters. Another difference is that his system allows for local changes of parameters, while mine deliberately ensures that a parameter really has exactly one value during one execution of the program. Finally, I’d say that my approach is easier to grasp and use by the programmer. Greetings, Joachim ¹ I guess the same approach works even when parameters are not tied to a specific module, but live on their own. But I guess for clarity of syntax and use it makes sense to tie them to modules, at least at first. -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Smarter do notation
On 5 September 2011 15:49, Sebastian Fischer fisc...@nii.ac.jp wrote: On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling nomin...@googlemail.com wrote: a = \p - f $ b -- 'free p' and 'free b' disjoint -- ((\p - f) $ a) * b Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb - f ...) a b I think I remember someone saying that the one-at-a-time application of * inhibits certain optimisations. liftA2 is defined via one-at-a-time application and cannot be redefined because it is no method of Applicative. Do you remember more details? Good point. I can't find the original post, so I don't know what exactly the issue was (or maybe I'm misremembering). -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solving the configuration problem with parametrized modules
Joachim Breitner wrote: The big downside is the verbosity of the approach: A lot of parameters need to be passed, and if one such value is suddenly required in a function where it was not before, this function’s signature and all functions using it have to be modified. Also, I expect that the explicit passing causes a small performance penalty. Can't this be mostly solved by putting all these configuration parameters in a struct and then using implicit parameters: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#implicit-parameters The nice thig about this approach is that is not a single unsafe operation needed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package descriptions on hackage
On 5 September 2011 23:59, Joachim Breitner m...@joachim-breitner.de wrote: Dear hackage package authors, this is a short message from your distribution package creators: Please, if possible, write good, not too short descriptions, and also keep them up to date. Of course, users browsing hackage will benefit as well. Also for potential users trying to work out what your library does! Something that I find particularly frustrating is all the libraries of the form hFoo: Haskell bindings to the Foo library; well, what _is_ the Foo library? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solving the configuration problem with parametrized modules
On Mon, Sep 5, 2011 at 3:15 PM, Erik de Castro Lopo mle...@mega-nerd.comwrote: Can't this be mostly solved by putting all these configuration parameters in a struct and then using implicit parameters: Implicit parameters seem like a fair option. And propagating: (?fooConf :: FooConf) = ... isn't any more difficult than explicit parameters in the type. I guess the question is whether it is the parameterization or the *staging *that seems more relevant. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
