Re: [Haskell-cafe] Reaching Max Bolingbroke

[Ben Lippmeier]

On 19/11/2012, at 24:40 , Roman Cheplyaka wrote:

> For the last two months I've been trying to reach Max Bolingbroke via
> his hotmail address, github and linkedin, but did not succeed.
> 
> Does anyone know if he's well? If someone could help by telling him that
> I'd like to get in touch, I'd appreciate that.

He wasn't at ICFP either. I think SPJ said he was in the middle of writing up 
his PhD thesis.

When I was doing mine I was out of circulation for a good 3 months.

Ben.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List all multiply/add combinations

[Stefan Klinger]

Well, at least this is a nice exercise!

I'm assuming that all operators associate to the left, and use the usual
precedence rules.

My approach would consider (1+2)+3 different from 1+(2+3), and enumerate
it again.  Of course they are different computations, though
mathematically equivalent.  Jonas' approach is better here, but it seems
to miss X/(X/X) — not tested, it's just not in his email.  But then the
equivalent X/X*X is present.

So... what kind of equivalences *exactly* do you want to omit?


Here's some code for my somewhat more permissive solution:

> data Expr
> = Val Float
> | Op Char Expr Expr
> deriving (Eq)

> instance Show Expr where
> showsPrec _ (Val v)
> = shows v
> showsPrec p (Op o e1 e2)
> = showParen (p>q)
>   $ showsPrec q e1 . showString [' ',o,' '] . showsPrec (q+1) e2
> where
> q = case o of
>   '+' -> 1
>   '-' -> 1
>   '*' -> 3
>   '/' -> 3

Split a sequence in two non-empty sequences at all possible places.

> allSplits :: [a] -> [([a],[a])]  -- ok, this is ugly
> allSplits xs = [splitAt n xs | n <- [1 .. length xs - 1]]

Calculate all ASTs.
  
> exps [x] = [Val x]
> exps xs = [ Op o l r
>   | (as,bs) <- allSplits xs
>   , l <- exps as
>   , r <- exps bs
>   , o <- "+-*/"
>   ]

putStr . unlines . map show $ exps [1..3]



-- 
Stefan Klinger  o/klettern
/\/  bis zum
send plaintext only - max size 32kB - no spam \   Abfallen
http://stefan-klinger.de

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List all multiply/add combinations

[Artyom Kazak]

Jonas Almström Duregård  писал(а) в своём  
письме Mon, 19 Nov 2012 01:31:01 +0300:



Hi,

You can make a datatype that captures exactly the expressions you want  
(see

code below). Essentially you want to make sure that a subtraction or
addition never has another subtraction or addition as its left operand.



I would also like to advertise a bit and show how this type can be
enumerated automatically by Feat (
http://hackage.haskell.org/package/testing-feat).


After a quick look, Feat seems to be awesome. Thanks! I don’t yet know how  
I am going to use it, but I hope an opportunity will present itself soon :)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List all multiply/add combinations

[Jonas Almström Duregård]

Hi,

You can make a datatype that captures exactly the expressions you want (see
code below). Essentially you want to make sure that a subtraction or
addition never has another subtraction or addition as its left operand.

I would also like to advertise a bit and show how this type can be
enumerated automatically by Feat (
http://hackage.haskell.org/package/testing-feat).

Main> nvars 3
(24,[X/X-X,X*X-X,X/X+X,X*X+X,X-X-X,X-X+X,X-X/X,X-X*X,X+X-X,X+X+X,X+X/X,X+X*X,(X-X)/X,(X+X)/X,(X-X)*X,(X+X)*X,X/(X-X),X/(X+X),X/X/X,X/X*X,X*(X-X),X*(X+X),X*X/X,X*X*X])

(Obviously the Xs need to be replaced by proper variables, I can explain
how that's done if anyone wants to know)

24 is the number of values in the list, you can do fst $ nvars 100 to find
out that there are
317334467851069836531554283592442220021116
711774843850938552230690568780568787114173
2912210230558851072
values with 100 variables. You can even select any one of those values by
index or randomly select values with uniform distribution and use it with
QuickCheck (for instance to test that my experiments with showsPrec hasn't
messed everything up).


Pasted code: http://hpaste.org/77898

{-# LANGUAGE TemplateHaskell, DeriveDataTypeable #-}
import Test.Feat
import Data.Typeable

-- | Any expression
data AnyExpr = AnyAddSub AddSub
 | AnyMulDiv MulDiv
 | AnyVar
 deriving Typeable

-- | Expressions with a top level addition or subtraction
data MulDiv = MDOp Bool AddSub AnyExpr -- Left operand is add. or sub.
| MDOpVar Bool AnyExpr -- Left operand is a variable
deriving Typeable

-- | Expressions with a top level multiplication or division
data AddSub = ASOp Bool MulDiv AnyExpr -- Left operand is mult. or div.
| ASOpVar Bool AnyExpr -- Left operand is a variable
deriving Typeable

deriveEnumerable ''AnyExpr
deriveEnumerable ''AddSub
deriveEnumerable ''MulDiv

allExpressions = values :: [(Integer,[AnyExpr])]
nvars n = allExpressions !! ((n-1)*3+1)

instance Show AnyExpr where
  showsPrec d (AnyAddSub e) = showsPrec d e
  showsPrec d (AnyMulDiv e) = showsPrec d e
  showsPrec _ (AnyVar)  = ("X"++)
instance Show AddSub where
  showsPrec d (ASOpVar b e)  = showParen (d > 6) $ ("X"++) . ((if b then
"+" else "-")++) . showsPrec 6 e
  showsPrec d (ASOp b e1 e2) = showParen (d > 6) $ showsPrec 6 e1 . ((if b
then "+" else "-")++) . showsPrec 6 e2
instance Show MulDiv where
  showsPrec d (MDOpVar b e)  = showParen (d > 7) $ ("X"++) . ((if b then
"*" else "/")++) . showsPrec 7 e
  showsPrec d (MDOp b e1 e2) = showParen (d > 7) $ showsPrec 7 e1 . ((if b
then "*" else "/")++) . showsPrec 7 e2



On 18 November 2012 20:31, Rune Harder Bak  wrote:
>
> On Sun, Nov 18, 2012 at 2:04 PM, Stefan Klinger
>  wrote:
> > Sounds like you would want to enumerate all possible *abstract* syntax
> > trees, these implicitly have exactly the necessary parentheses.  I'd do
> > this recursively, splitting the sequence of numbers in two at all
> > possible places, and then combine the corresponding results with all
> > possible operators.
>
> That was my second idea, but just doing it naively resulted in many
> equivalent calculations,
> so I thought there might be a better way to view the problem.
> But as Artyom showed
>
> On Sat, Nov 17, 2012 at 11:37 PM, Artyom Kazak 
wrote:
> > Indentation messed up… I have pasted the code here:
http://hpaste.org/77864
>
> enumerating the abstract syntax tree is actually (or at least could
> be) the way to go!
> Thanks a lot! What I need is a little bit different, but now I feel
> I'm on the right track!
>
> This is my first question to the café and it makes me a lot more
> certain using Haskell for production,
> when you can get this kind of quick and thorough help when in doubt.
>
> Great community!
>
> -Rune
>
> ___
> 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] Automation of external library installation in haskell package.

[Roman Cheplyaka]

* Johan Tibell  [2012-11-18 12:28:50-0800]
> Hi,
> 
> On Sun, Nov 18, 2012 at 11:51 AM, Maksymilian Owsianny <
> maksymilian.owsia...@gmail.com> wrote:
> 
> > However, the problem with hackage not being able to build the package, and
> > therefore generate documentation, remains. So conversely my question would
> > be
> > if there is any way to get around this?
> >
> 
> In the short term I'm afraid not. The plan is to eventually let users
> upload the documentation (after building it on their own machines).

Another option would be to add a configuration flag in the cabal file
that would disable compiling the library-dependent code (probably
through CPP). The only problem with that is that it needs to be enabled
by default (since we don't know whether we're building on hackage or
not) and needs to be explicitly disabled by normal users.

Unfortunately, cabal cannot automatically set the flag depending on
whether the library is installed or not.
I wrote about it in June (and got no response):
http://www.haskell.org/pipermail/cabal-devel/2012-June/008908.html

Roman

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [repa] beginner questions

[Dominic Steinitz]

Dmitry Malikov  gmail.com> writes:

> 
> Playing around with repa arrays and got some questions.
> 
> 1) How I can get list of indexes of array that suffice some predicate?
> 
>  > a1
>  AUnboxed (Z :. 3) (fromList [False,False,True])
>  it :: Array U (Z :. Int) Bool
> 
> Indexes of element that satisfying specific predicate could be obtained 
> like that:
> 
>  > (\a p → Data.List.map (subtract 1 . snd) $ filter (p . fst) $ zip 
> (toList a) [1..]) a1 (== False)
>  [0,1]
> 
> Looks ugly. How REPA users used to do filtering like that without 
> converting to list?
> 

I hope someone will correct me if I am wrong and furthermore I was not
entirely clear what you were trying to do but it seems to me that if you
want to filter out an unknown number of elements from a collection 
then repa is the wrong abstraction to use.

You can however filter out a known number of elements e.g.

xs = Repa.fromListUnboxed (Z :. 3) [1, 2, 3]

removeOne ix xs = Repa.fromFunction
   (Z :. dx - 1)
   (\(Z :. jx) -> xs ! (Z :. f jx))
   where
 Z :. dx = Repa.extent xs
 f jx | jx < ix   = jx
   | otherwise = jx + 1

test = Repa.computeP $ removeOne 1 xs :: IO (Array U DIM1 Float)

Does that help?

Dominic.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Automation of external library installation in haskell package.

[Johan Tibell]

Hi,

On Sun, Nov 18, 2012 at 11:51 AM, Maksymilian Owsianny <
maksymilian.owsia...@gmail.com> wrote:

> However, the problem with hackage not being able to build the package, and
> therefore generate documentation, remains. So conversely my question would
> be
> if there is any way to get around this?
>

In the short term I'm afraid not. The plan is to eventually let users
upload the documentation (after building it on their own machines).

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Automation of external library installation in haskell package.

[Maksymilian Owsianny]

Hi Johan,

Originally, that was my intention, to have the user install the library
himself,
and I have specified the extra-libraries field in the .cabal file.

However, the problem with hackage not being able to build the package, and
therefore generate documentation, remains. So conversely my question would
be
if there is any way to get around this?

Best regards,
Max.

On Sun, Nov 18, 2012 at 8:21 PM, Johan Tibell wrote:

> Hi Maksymilian,
>
> Generally I don't recommend that you bundle C libraries with your
> Cabal package. On Linux users should get C libraries through their
> distribution's package manager. The people who package Cabal packages
> for Debian (as Debian packages) can then have the Debian package they
> create depend on the C library's package, making sure it gets
> installed automatically.
>
> You can list the library name in an extra-libraries field in your
> .cabal file to communicate to users that they need this library
> installed. There's a little bit of documentation on the
> extra-libraries field in the Cabal User Guide
> (http://www.haskell.org/cabal/users-guide/developing-packages.html#library
> ).
>
> Cheers,
> Johan
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List all multiply/add combinations

[Rune Harder Bak]

On Sun, Nov 18, 2012 at 2:04 PM, Stefan Klinger
 wrote:
> Sounds like you would want to enumerate all possible *abstract* syntax
> trees, these implicitly have exactly the necessary parentheses.  I'd do
> this recursively, splitting the sequence of numbers in two at all
> possible places, and then combine the corresponding results with all
> possible operators.

That was my second idea, but just doing it naively resulted in many
equivalent calculations,
so I thought there might be a better way to view the problem.
But as Artyom showed

On Sat, Nov 17, 2012 at 11:37 PM, Artyom Kazak  wrote:
> Indentation messed up… I have pasted the code here: http://hpaste.org/77864

enumerating the abstract syntax tree is actually (or at least could
be) the way to go!
Thanks a lot! What I need is a little bit different, but now I feel
I'm on the right track!

This is my first question to the café and it makes me a lot more
certain using Haskell for production,
when you can get this kind of quick and thorough help when in doubt.

Great community!

-Rune

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Automation of external library installation in haskell package.

[Maksymilian Owsianny]

Hello Haskell-Cafe,

I have created a package that requires an external library to be present on
the machine.
Because of that, obviously, hackage fails to build it, and subsequently
fails to generate
documentation.

So my question is, how should I go about configuring Cabal/Setup.hs to
automatize the
process to allow hackage to build it properly and also simplify the package
installation
for the user.

The packages that I'm talking about are bindings to
Awesomium
:
awesomium-raw 
and subsequently, the higher level ones that depend on it
awesomium 
awesomium-glut 

Specifically, the installation process for linux is described as follows:

To install Awesomium, you'll need to add the shared library to your
> system's library search path. On Ubuntu, you can use the following
> commands:
>
> cd awesomium_v1.6.5_sdk_linux32
> sudo mkdir /usr/lib/awesomium-1.6.5
> sudo cp -r build/bin/release/* /usr/lib/awesomium-1.6.5
> sudo ldconfig /usr/lib/awesomium-1.6.5
>
>

So if anyone could give me some hints, or point me to package that have a
similar,
external-library-copying-and-registering installation process i would be
grateful.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsing different types, same typeclass

[Jose A. Lopes]

Thanks Stephen, that worked out just fine!

On 18-11-2012 18:23, Jose A. Lopes wrote:

Thanks Stephen. I will try this!

On 18-11-2012 17:56, Stephen Tetley wrote:

With existentials an "extesible" version might look like this:


{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}


... class Action and datatypes A and B the same as before ...



-- some new ones...
data C = C Int
  deriving (Read, Show)



instance Action C where
  run (C n) = n



data D = D Int
  deriving (Read, Show)
instance Action D where
  run (D n) = n


The important one:


data PolyA = forall a. Action a => PolyA a



parseAction :: String -> PolyA
parseAction str
  | "(A " `isPrefixOf` str = PolyA $ (read :: String -> A) str
  | "(B " `isPrefixOf` str = PolyA $ (read :: String -> B) str

  -- can add new cases
  | "(C " `isPrefixOf` str = PolyA $ (read :: String -> C) str
  | "(D " `isPrefixOf` str = PolyA $ (read :: String -> D) str


This is "extensible" to some degree as you can add new cases of
"different" types, but all you can do with these different types is
run them to make an Int, so it is equivalent to the second version I
gave previously:


parseAction :: String -> Int
parseAction str
 | "(A " `isPrefixOf` str = run $ (read str :: A)
 | "(B " `isPrefixOf` str = run $ (read str :: B)
 | "(C " `isPrefixOf` str = run $ (read str :: C)
 | "(D " `isPrefixOf` str = run $ (read str :: D)

i.e instead of using an existential type to hold something polymorphic
that can be run to produce an Int, just call run at the point of use
making an Int.




--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsing different types, same typeclass

[Jose A. Lopes]

Thanks Stephen. I will try this!

On 18-11-2012 17:56, Stephen Tetley wrote:

With existentials an "extesible" version might look like this:


{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}


... class Action and datatypes A and B the same as before ...



-- some new ones...
data C = C Int
  deriving (Read, Show)



instance Action C where
  run (C n) = n



data D = D Int
  deriving (Read, Show)
instance Action D where
  run (D n) = n


The important one:


data PolyA = forall a. Action a => PolyA a



parseAction :: String -> PolyA
parseAction str
  | "(A " `isPrefixOf` str = PolyA $ (read :: String -> A) str
  | "(B " `isPrefixOf` str = PolyA $ (read :: String -> B) str

  -- can add new cases
  | "(C " `isPrefixOf` str = PolyA $ (read :: String -> C) str
  | "(D " `isPrefixOf` str = PolyA $ (read :: String -> D) str


This is "extensible" to some degree as you can add new cases of
"different" types, but all you can do with these different types is
run them to make an Int, so it is equivalent to the second version I
gave previously:


parseAction :: String -> Int
parseAction str
 | "(A " `isPrefixOf` str = run $ (read str :: A)
 | "(B " `isPrefixOf` str = run $ (read str :: B)
 | "(C " `isPrefixOf` str = run $ (read str :: C)
 | "(D " `isPrefixOf` str = run $ (read str :: D)

i.e instead of using an existential type to hold something polymorphic
that can be run to produce an Int, just call run at the point of use
making an Int.


--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsing different types, same typeclass

[Jose A. Lopes]

Hey Chris,

Thanks for you reply!

So the thing is: I actually had an algebraic data type Action with
several constructors, one for each Action. And I was deriving
Read so there was no problem there.

However, I want to be able to add and remove Actions more easily.
That is why I transformed the algebraic data type into a typeclass.
Similarly, if you think about Object Oriented programming, I want
the flexibility of subclassing, where new subclasses can be added
without a problem. The fact that parseAction only works on a finite
number of Actions is not problematic for now!

So, I would really appreciate your help in overcoming this problem!

Best regards,
José

On 18-11-2012 03:08, Chris Wong wrote:

Hello José,


So, I have a typeclass "Action" which defines method "run":

class Action a where
 run :: a -> Int

(snipped)

Now, I want to parse either "A" or "B" from a String.
I was thinking about something like this...

parseAction :: (Action a, Read a) => String -> a
parseAction str
 | "(A " `isPrefixOf` str = (read :: String -> A) str
 | "(B " `isPrefixOf` str = (read :: String -> B) str

The problem is that when calling "parseAction" I get "ambiguous type
constraints". How to implement a parse function for two distinct
types that share the same typeclass "Action". Because after calling
"parseAction" I don't whether "A" or "B" was returned: I only care
that they are "Action" instances so I can call "run".

The problem with your current type:

 (Action a, Read a) => String -> a

is that it actually means:

 For any type that implements Action and Read, I can convert a
string to that type.

This is wrong because if a user of your module added another type C,
your function wouldn't be able to handle it -- it only "knows" about A
and B. That is what GHC is trying to tell you.

How you can solve this problem depends on what you're trying to do. If
there is a finite number of actions, you can merge them into a single
type and remove the type class altogether:

 data Action = A Int | B Int
 deriving (Read, Show)

 run :: Action -> Int
 run (A x) = x
 run (B x) = x

 parse :: String -> Action
 parse = read

If you have a possibly unlimited number of possible actions, there are
many approaches to this -- including, as Stephen said, existential
types. However, it's hard to decide on a proper solution without
knowing what you're actually trying to do.

Chris


Best regards,
José

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsing different types, same typeclass

[Stephen Tetley]

With existentials an "extesible" version might look like this:

> {-# LANGUAGE ExistentialQuantification #-}
> {-# LANGUAGE ScopedTypeVariables #-}


... class Action and datatypes A and B the same as before ...


> -- some new ones...

> data C = C Int
>  deriving (Read, Show)


> instance Action C where
>  run (C n) = n


> data D = D Int
>  deriving (Read, Show)

> instance Action D where
>  run (D n) = n


The important one:

> data PolyA = forall a. Action a => PolyA a


> parseAction :: String -> PolyA
> parseAction str
>  | "(A " `isPrefixOf` str = PolyA $ (read :: String -> A) str
>  | "(B " `isPrefixOf` str = PolyA $ (read :: String -> B) str
>
>  -- can add new cases
>  | "(C " `isPrefixOf` str = PolyA $ (read :: String -> C) str
>  | "(D " `isPrefixOf` str = PolyA $ (read :: String -> D) str


This is "extensible" to some degree as you can add new cases of
"different" types, but all you can do with these different types is
run them to make an Int, so it is equivalent to the second version I
gave previously:

> parseAction :: String -> Int
> parseAction str
> | "(A " `isPrefixOf` str = run $ (read str :: A)
> | "(B " `isPrefixOf` str = run $ (read str :: B)
> | "(C " `isPrefixOf` str = run $ (read str :: C)
> | "(D " `isPrefixOf` str = run $ (read str :: D)

i.e instead of using an existential type to hold something polymorphic
that can be run to produce an Int, just call run at the point of use
making an Int.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small step towards solving cabal hell.

[timothyhobbs]

You are correct this won't help(and may even hurt) in places where there is 
true mutual inter-dependency between parts of libraries.  But I gave 
examples where I was sure this was not the case.

Timothy


-- Původní zpráva --
Od: Brandon Allbery 
Datum: 18. 11. 2012
Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell.
"

On Sun, Nov 18, 2012 at 11:04 AM, Brandon Allbery mailto:allber...@gmail.com)> wrote:

" 

There's another consideration, which is are you optimizing hackage by 
pessimizing development?  You could break xmonad-contrib into (usually) one 
package per module if you really wanted to --- but now the developers need 
to track a couple hundred packages and possibly as many darcs or git or 
whatever repos. You've just nibbled that project to death by making it too 
difficult for developers to bother with.

"



It also occurs to me that you might have also made the original problem much
worse instead of better:  now we have a hundred or so micro-packages that 
can get into diamond or worse dependency conflicts, where there was only one
possible source of conflict.




-- 


brandon s allbery kf8nh                               sine nomine associates

allber...@gmail.com(mailto:allber...@gmail.com)                             
     ballb...@sinenomine.net(mailto:ballb...@sinenomine.net)
 
unix/linux, openafs, kerberos, infrastructure          http://sinenomine.net
(http://sinenomine.net)


 

"___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small step towards solving cabal hell.

[Brandon Allbery]

On Sun, Nov 18, 2012 at 11:04 AM, Brandon Allbery wrote:

> There's another consideration, which is are you optimizing hackage by
> pessimizing development?  You could break xmonad-contrib into (usually) one
> package per module if you really wanted to --- but now the developers need
> to track a couple hundred packages and possibly as many darcs or git or
> whatever repos. You've just nibbled that project to death by making it too
> difficult for developers to bother with.
>

It also occurs to me that you might have also made the original problem
much worse instead of better:  now we have a hundred or so micro-packages
that can get into diamond or worse dependency conflicts, where there was
only one possible source of conflict.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small step towards solving cabal hell.

[timothyhobbs]

I understand your concern.  Of course with cabals current implementation 
this proposal requires a lot of fluff.  I thought about implementing a cabal
syntax directly into Haskell pragmas, getting rid of the cabal file format 
entirely.  I think that would be a pie in the sky optimum.  However, I don't
think that such fluff is the death of my proposal.  Wikipedia seems 
unmaintainable after all, with so many hundreds of thousands of articles.  
Yet it is maintained by the sheer force of millions of contributors.  
Lowering the boundary for new contributors to step up and help maintain 
these new micro-packages, by shrinking and simplifying the packages, will 
solve the very problem it creates.




Timothy





-- Původní zpráva --
Od: Brandon Allbery 
Datum: 18. 11. 2012
Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell.
"

On Sun, Nov 18, 2012 at 10:15 AM, mailto:timothyho...@seznam.cz)> wrote:

" 
Well in some cases, it might not be easy to break up the libraries.  If 
there is sufficient mutual dependency, doing so won't even help the 
situation.  However, I already looked at the code to some large libraries, 
such as xmonad-contrib, and gtk2hs and am certain that no code modifications
are needed for these libraries to be broken into more manageable "books".  
Often times, like is the case with 
"



There's another consideration, which is are you optimizing hackage by 
pessimizing development?  You could break xmonad-contrib into (usually) one 
package per module if you really wanted to --- but now the developers need 
to track a couple hundred packages and possibly as many darcs or git or 
whatever repos. You've just nibbled that project to death by making it too 
difficult for developers to bother with.




(cabal doesn't really let you have multiple packages per source tree 
currently; this would help some, but I suspect that would just expose more 
shortcomings in hackage with that kind of package setup.)




-- 


brandon s allbery kf8nh                               sine nomine associates

allber...@gmail.com(mailto:allber...@gmail.com)                             
     ballb...@sinenomine.net(mailto:ballb...@sinenomine.net)
 
unix/linux, openafs, kerberos, infrastructure          http://sinenomine.net
(http://sinenomine.net)


 

"___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small step towards solving cabal hell.

[Brandon Allbery]

On Sun, Nov 18, 2012 at 10:15 AM,  wrote:

> Well in some cases, it might not be easy to break up the libraries.  If
> there is sufficient mutual dependency, doing so won't even help the
> situation.  However, I already looked at the code to some large libraries,
> such as xmonad-contrib, and gtk2hs and am certain that no code
> modifications are needed for these libraries to be broken into more
> manageable "books".  Often times, like is the case with
>

There's another consideration, which is are you optimizing hackage by
pessimizing development?  You could break xmonad-contrib into (usually) one
package per module if you really wanted to --- but now the developers need
to track a couple hundred packages and possibly as many darcs or git or
whatever repos. You've just nibbled that project to death by making it too
difficult for developers to bother with.

(cabal doesn't really let you have multiple packages per source tree
currently; this would help some, but I suspect that would just expose more
shortcomings in hackage with that kind of package setup.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small step towards solving cabal hell.

[timothyhobbs]

Well in some cases, it might not be easy to break up the libraries.  If 
there is sufficient mutual dependency, doing so won't even help the 
situation.  However, I already looked at the code to some large libraries, 
such as xmonad-contrib, and gtk2hs and am certain that no code modifications
are needed for these libraries to be broken into more manageable "books".  
Often times, like is the case with xmonad-contrib and gtk2hs you have a core
library that is required by a large "cluster" of smaller modules.  But those
smaller modules are not mutually required between themselves.  From a 
technical standpoint, it might be nice to have a way to declare such a 
grouping within hackage or cabal, but no technical change is necessary for 
the philosophical change I am recommending.

One thing I certainly don't want to do, is to "strong arm" library 
maintainers into breaking up their mega-packages into more easily maintained
parts ;)  This has to be a decision made by the individual package 
maintainers, rather than some "policy" that comes down from "those who know 
best" upon the shoulders of the hard working members of our community...




Timothy



-- Původní zpráva --
Od: Alfredo Di Napoli 
Datum: 18. 11. 2012
Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell.
"
Hi Tim,
it seems a good idea, although I hardly believe such isolation is achievable
in practice. Just a feeling, though :)

However, I really hope we, as a community, will be able to finally fix the 
Cabal Hell. It's a topic with a lot of hype lately,

but few "practical, hands dirty" approaches :)




Cheers,

Alfredo



On 18 November 2012 13:33, mailto:timothyho...@seznam.cz)> wrote:
"
I've read a lot of negative regarding the problems with cabal and hackage.
I've written quite a few of them myself.

I want to propose a simple change in philosophy of packages.

Haskell has inherited a philosophy from the imperative world,
that there are two types of packages:
Libraries and applications.

Libraries are big collections of modules.
Applications are big collections of modules.

There is a difference from the perspective of the build system.  

Applications are big collections of modules that belong together and 
mutually rely upon each other for the application to work. Such that if one 
module is missing, the application cannot build and thus cannot do useful 
tasks.  If an application doesn't build, then the maintainer has to go and 
fix that problem.  This isn't perfect, I do not solve this problem in this 
email.

Libraries don't always have this property.
For example, XMonad.Layout.Column
(http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Column.html)
has no mutual dependency on XMonad.Layout.Circle
(http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Circle.html)
.

This is a feature of libraries that can and should be taken advantage of 
wherever possible :)

We can and should,
break up libraries into "books".

I hold this opinion,
because libraries are hard to maintain.

If xmonad-contrib refuses to build,
I open up it's source code,
and see some hundred modules.

I cannot,
as a non-xmonad developer,
imagine myself fixing such a large library.
But if it was just one small module from that library I wanted,
and it refused to build,
and I opened it up,
and there were just 3 files there.
I wouldn't feel so overwhelmed.

I would fix the problem myself.

What I'm trying to say,
is that "books"
(small packages containing 3 modules or less)
are so easy to maintain,
that they really need no maintainer at all.
Any idiot can fix one.

But libraries,
with their hundreds of modules,
and seemingly endless dependencies,
Can be much harder to maintain,
and require a knowledgeable maintainer.

So lets stop publishing libraries,
and maintaining libraries,
and listening to people crying when libraries don't build,
and lets start writing books,
and publishing really small packages,
that are so simple anyone can fix them when they break
even when they have no in depth knowledge of the package.

Lets make a new guideline for "libraries"
that if it is possible to split a library into two or more,
non-mutually dependent parts,
than we *should* split them such.

Timothy

PS,

I noticed that yesod is already a collection of "books",
but it appears to me, that these packages are STILL mutually dependent :(


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org(mailto:Haskell-Cafe@haskell.org)
http://www.haskell.org/mailman/listinfo/haskell-cafe
(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] A small step towards solving cabal hell.

[Alfredo Di Napoli]

Hi Tim,
it seems a good idea, although I hardly believe such isolation is
achievable in practice. Just a feeling, though :)
However, I really hope we, as a community, will be able to finally fix the
Cabal Hell. It's a topic with a lot of hype lately,
but few "practical, hands dirty" approaches :)

Cheers,
Alfredo

On 18 November 2012 13:33,  wrote:

> I've read a lot of negative regarding the problems with cabal and hackage.
> I've written quite a few of them myself.
>
> I want to propose a simple change in philosophy of packages.
>
> Haskell has inherited a philosophy from the imperative world,
> that there are two types of packages:
> Libraries and applications.
>
> Libraries are big collections of modules.
> Applications are big collections of modules.
>
> There is a difference from the perspective of the build system.
>
> Applications are big collections of modules that belong together and
> mutually rely upon each other for the application to work. Such that if one
> module is missing, the application cannot build and thus cannot do useful
> tasks.  If an application doesn't build, then the maintainer has to go and
> fix that problem.  This isn't perfect, I do not solve this problem in this
> email.
>
> Libraries don't always have this property.
> For example, 
> XMonad.Layout.Columnhas
>  no mutual dependency on
> XMonad.Layout.Circle
> .
>
> This is a feature of libraries that can and should be taken advantage of
> wherever possible :)
>
> We can and should,
> break up libraries into "books".
>
> I hold this opinion,
> because libraries are hard to maintain.
>
> If xmonad-contrib refuses to build,
> I open up it's source code,
> and see some hundred modules.
>
> I cannot,
> as a non-xmonad developer,
> imagine myself fixing such a large library.
> But if it was just one small module from that library I wanted,
> and it refused to build,
> and I opened it up,
> and there were just 3 files there.
> I wouldn't feel so overwhelmed.
>
> I would fix the problem myself.
>
> What I'm trying to say,
> is that "books"
> (small packages containing 3 modules or less)
> are so easy to maintain,
> that they really need no maintainer at all.
> Any idiot can fix one.
>
> But libraries,
> with their hundreds of modules,
> and seemingly endless dependencies,
> Can be much harder to maintain,
> and require a knowledgeable maintainer.
>
> So lets stop publishing libraries,
> and maintaining libraries,
> and listening to people crying when libraries don't build,
> and lets start writing books,
> and publishing really small packages,
> that are so simple anyone can fix them when they break
> even when they have no in depth knowledge of the package.
>
> Lets make a new guideline for "libraries"
> that if it is possible to split a library into two or more,
> non-mutually dependent parts,
> than we *should* split them such.
>
> Timothy
>
> PS,
>
> I noticed that yesod is already a collection of "books",
> but it appears to me, that these packages are STILL mutually dependent :(
>
> ___
> 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] Reaching Max Bolingbroke

[Roman Cheplyaka]

For the last two months I've been trying to reach Max Bolingbroke via
his hotmail address, github and linkedin, but did not succeed.

Does anyone know if he's well? If someone could help by telling him that
I'd like to get in touch, I'd appreciate that.

Roman

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] A small step towards solving cabal hell.

[timothyhobbs]

I've read a lot of negative regarding the problems with cabal and hackage.
I've written quite a few of them myself.

I want to propose a simple change in philosophy of packages.

Haskell has inherited a philosophy from the imperative world,
that there are two types of packages:
Libraries and applications.

Libraries are big collections of modules.
Applications are big collections of modules.

There is a difference from the perspective of the build system.  

Applications are big collections of modules that belong together and 
mutually rely upon each other for the application to work. Such that if one 
module is missing, the application cannot build and thus cannot do useful 
tasks.  If an application doesn't build, then the maintainer has to go and 
fix that problem.  This isn't perfect, I do not solve this problem in this 
email.

Libraries don't always have this property.
For example, XMonad.Layout.Column
(http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Column.html)
has no mutual dependency on XMonad.Layout.Circle
(http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Circle.html)
.

This is a feature of libraries that can and should be taken advantage of 
wherever possible :)

We can and should,
break up libraries into "books".

I hold this opinion,
because libraries are hard to maintain.

If xmonad-contrib refuses to build,
I open up it's source code,
and see some hundred modules.

I cannot,
as a non-xmonad developer,
imagine myself fixing such a large library.
But if it was just one small module from that library I wanted,
and it refused to build,
and I opened it up,
and there were just 3 files there.
I wouldn't feel so overwhelmed.

I would fix the problem myself.

What I'm trying to say,
is that "books"
(small packages containing 3 modules or less)
are so easy to maintain,
that they really need no maintainer at all.
Any idiot can fix one.

But libraries,
with their hundreds of modules,
and seemingly endless dependencies,
Can be much harder to maintain,
and require a knowledgeable maintainer.

So lets stop publishing libraries,
and maintaining libraries,
and listening to people crying when libraries don't build,
and lets start writing books,
and publishing really small packages,
that are so simple anyone can fix them when they break
even when they have no in depth knowledge of the package.

Lets make a new guideline for "libraries"
that if it is possible to split a library into two or more,
non-mutually dependent parts,
than we *should* split them such.

Timothy

PS,

I noticed that yesod is already a collection of "books",
but it appears to me, that these packages are STILL mutually dependent :(
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe