Re: [Haskell-cafe] cabal problem on OS X

[Jeroen Weijers]

Hi,

For me it turned out to be some problem with MacPorts, removing
MacPorts (with all its installed ports) solved the problem regarding
ZLib. I assume that a less drastic measure would also work (only
remove selected ports or remove the ports from your path).

Regards,

Jeroen

2010/6/9 Christopher Done :
> I am also experiencing this problem.
>
> I read that the problem was fixed in the latest Cabal-install version.
> But I'm not sure, as I tried to install the latest Cabal-install and
> got 50 linker errors which I'm not prepared to tackle until the
> weekend.
>
> On 8 June 2010 18:21, Gordon J. Uszkay  wrote:
>> Did you manage to fix this problem, or are there any updates on it?  I am 
>> now having the same issue - presumably due to updating my Mac OS X version, 
>> because cabal was working fine before that.  I can't upgrade cabal or 
>> install anything either, same reason.
>>
>> Gordon J. Uszkay
>> uszka...@mcmaster.ca
>>
>>
>>
>> On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote:
>>
>>> Bill Atkins  writes:
>>>
 When I run "cabal update" on my Mac (Snow Leopard, Intel), I get:

 % cabal update
 Downloading the latest package list from hackage.haskell.org
 cabal: Codec.Compression.Zlib: incompatible zlib version
>>>
>>> I'm going to randomly guess that the version of the C zlib library that
>>> Cabal was indirectly built against is different to the one on your
>>> machine.
>>>
>>> --
>>> 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
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Stone age programming for space age hardware?

[Brandon S. Allbery KF8NH]

On Jun 8, 2010, at 14:22 , Michael Schuerig wrote:

On Tuesday 08 June 2010, Heinrich Apfelmus wrote:

I have absolutely no experience with real time system, but if I were
tasked to write with these coding standards, I would refuse and
instead create a small DSL in Haskell that compiles to the requested
subset of C.


Now, the interesting question is, whether it is possible to define a  
DSL

that's expressive enough and still can be translated to a very
restrictive subset of C. I wouldn't expect the on-board  
functionality of

a space probe or rover to be trivial.


Hm.  Atom?

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Proposal to solve Haskell's MPTC dilemma

[Brandon S. Allbery KF8NH]

On Jun 8, 2010, at 15:32 , Job Vranish wrote:

It seems like this would make working with MPTCs much easier.
When programming, I generally want to only specify the minimum  
amount of information to make my code logically unambiguous.
If the code contains enough information to infer the proper  
instantiation without the use of an FD, then I shouldn't need to add  
a FD.
It seems like this would have much more of a "it just works" feel  
than the currently alternatives.


I can't help but think that the "it just works" mentality leads to  
duck typing.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Re: Rewriting a famous library and using the same name: pros and consf

[Ivan Miljenovic]

On 9 June 2010 12:11, Jason Dagit  wrote:
>
> Or write translator tools for upgrading to the new API :)  Pipe dream?
>  Maybe.

Too an extent, yes: the types are more generalised so it's going to be
difficult to do automatic translations.

However, Thomas has demonstrated that you can write any instance of
the new class as an instance of the old classes and vice versa just
using class methods...

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

[Haskell-cafe] Tricks with GMap -- question about conflicts w/ indexed type families

[oleg]

Ryan Newton wrote:

> What I would next *like* to do is something like the following:
>
> import qualified Data.IntMap as DI
> instance FitInWord t => GMapKey t where
>  data GMap t v   = GMapInt (DI.IntMap v) deriving Show
>
> The problem is that there's already a more general instance of GMapKey
> that handles pairs by representing them as nested GMaps:
>
> instance (GMapKey a, GMapKey b) => GMapKey (a, b) where
>   data GMap (a, b) v= GMapPair (GMap a (GMap b v))
>   
>
> Ideally, I want both of these to coexist (and to prioritize the more
> specific one).  With normal type classes, OverlappingInstances can
> handle this,  but with type families I get an error like the
> following:

First of all, if we forget about data families, OverlappingInstances
still won't give us the desired behavior. GHC chooses overlapping
instances based only on the instance head type, disregarding all
constraints. Therefore, when asked to choose an instance for
GMapKey (Int16,Int16), GHC would choose the second instance as it is
more specific: the type (a,b) is more specific that the type t. Again,
the constraints such as FitInWord are not used when choosing instances.
This issue is discussed in detail at

Choosing a type-class instance based on the context
http://okmij.org/ftp/Haskell/types.html#class-based-overloading
and on the Wiki Page
http://haskell.org/haskellwiki/GHC/AdvancedOverlap

These pages explain how can we make class constraints bear on the
instance selection.

But we still have the second problem: data families do not permit
overlapping declarations. At first blush, it appears impossible to
define GMapKey for specific pairs and default to the generic GMap
instance for general pairs. Fortunately, a solution exists, shown
below. The idea is to define an auxiliary type class (without data
families). Such a type class permits overlapping instances and so
makes possible the desired behavior of specific instances with the
generic default.

{-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverlappingInstances #-}

module GM where

import Data.Int
import Data.Word
import Data.Bits
import qualified Data.IntMap as IM

-- = Begin a simplified GMap package
-- A simplified class GMapKey
class GMapKey t where
data GMap t :: * -> *
empty :: GMap t v
lookup :: t -> GMap t v -> Maybe v

instance GMapKey Int16 where
data GMap Int16 v = GMI16 (IM.IntMap v)
empty  = GMI16 $ IM.empty
lookup k (GMI16 m) = IM.lookup (fromIntegral k) m

instance GMapKey Int32 where
data GMap Int32 v = GMI32 (IM.IntMap v)
empty  = GMI32 $ IM.empty
lookup k (GMI32 m) = IM.lookup (fromIntegral k) m

-- Generic instance for pairs
instance (GMapKey a, GMapKey b) => GMapKey (a, b) where
  data GMap (a, b) v= GMapPair (GMap a (GMap b v))
  empty = GMapPair $ empty
  lookup k (GMapPair m) = error "Invoking the generic instance for pairs"

-- = End the simplified GMap package

-- The following is an optimization, which should appear in a different
-- module. The optimization should not disturb the original GMap code.
-- The following optimization is Ryan Newton's code

-- A class for values that fit within one word
class FitInWord v where
  toWord   :: v -> Word
  fromWord :: Word -> v

instance FitInWord (Int16,Int16) where
  toWord (a,b) = shiftL (fromIntegral a) 16 + (fromIntegral b)
  fromWord n = (fromIntegral$ shiftR n 16,
fromIntegral$ n .&. 0x)

-- Now we wish to define optimized instances of GMapKey for
-- pairs of items that fit within a word.
-- The following answers Ryan Newton's question

-- Define our own product type, to avoid overlapping instances with the
-- general GMapKey for pairs
-- It's a newtype: it has no run-time overhead
newtype OptimalPair a b = OptimalPair (a,b)

instance FitInWord (a,b) => GMapKey (OptimalPair a b) where
  data GMap (OptimalPair a b) v  = GMapInt (IM.IntMap v) deriving Show
  empty   = GMapInt IM.empty
  lookup (OptimalPair k) (GMapInt m)  = IM.lookup (fromIntegral$ toWord k) m

-- Auxiliary class to choose the appropriate pair

class ChoosePairRepr a b pr | a b -> pr where
choose_pair  :: (a,b) -> pr
choosen_pair :: pr -> (a,b)

instance ChoosePairRepr Int16 Int16 (OptimalPair Int16 Int16) where
choose_pair = OptimalPair
choosen_pair (OptimalPair p) = p

-- Repeat the above for all other optimal pairs:
-- (Int8, Int16), (Int16, Int8), etc.
-- Template Haskell is very good to generate all such boiler-plate instances

-- Choose a generic pair for all other pairs of values
instance pr ~ (a,b) => ChoosePairRepr a b pr where
choose_pair   = id
choosen_pair  = id

-- tests

-- A specific instance is chosen
test1 = let m = empty in
GM.lookup (choose_pair (1::Int16,2::Int16)) m
-- Nothing

-- A general pair insta

Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf

[Jason Dagit]

On Tue, Jun 8, 2010 at 6:28 PM, John Lato  wrote:

> > From: Stephen Tetley 
> >
> > Hello all
> >
> > While new libraries develop at pace, their documentation rarely does;
> > so I'd have to disagree with John's claim that re-naming libraries
> > makes development by new users harder. I'd argue that having tutorials
> > not work for later revisions is more confusing than having various
> > packages doing the same thing. I'd also contend that beginners are
> > better off lagging behind the cutting edge and using Parsec 2,
> > QuickCheck 1, Haskore-vintage, as the earlier version all have
> > comprehensive documentation - Parsec 2 and Haskore have extensive
> > manual/tutorials, QuickCheck 1 was small enough that the original
> > QuickCheck paper covered its use.
>
> Lagging behind the cutting edge is one thing, but learning
> possibly-deprecated or soon-to-be-obsolete interfaces is another.  I
> would contend that in each case the intention is for the earlier
> version to be superseded because of significant (hopefully
> user-driven) benefits provided by the new design.  Now beginners are
> in the very frustrating situation of having invested time with a
> codebase that they learn is obsolete.  Depending on the significance
> of the changes, some amount of that knowledge can be carried forward,
> but it's a disheartening position to be in and I would expect a few
> could give up entirely at that point.  I think that's worse than
> floundering around with no documentation at all.
>
> Of course a better solution is for maintainers to update their manuals!
>

Or write translator tools for upgrading to the new API :)  Pipe dream?
 Maybe.

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

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf

[John Lato]

> From: Stephen Tetley 
>
> Hello all
>
> While new libraries develop at pace, their documentation rarely does;
> so I'd have to disagree with John's claim that re-naming libraries
> makes development by new users harder. I'd argue that having tutorials
> not work for later revisions is more confusing than having various
> packages doing the same thing. I'd also contend that beginners are
> better off lagging behind the cutting edge and using Parsec 2,
> QuickCheck 1, Haskore-vintage, as the earlier version all have
> comprehensive documentation - Parsec 2 and Haskore have extensive
> manual/tutorials, QuickCheck 1 was small enough that the original
> QuickCheck paper covered its use.

Lagging behind the cutting edge is one thing, but learning
possibly-deprecated or soon-to-be-obsolete interfaces is another.  I
would contend that in each case the intention is for the earlier
version to be superseded because of significant (hopefully
user-driven) benefits provided by the new design.  Now beginners are
in the very frustrating situation of having invested time with a
codebase that they learn is obsolete.  Depending on the significance
of the changes, some amount of that knowledge can be carried forward,
but it's a disheartening position to be in and I would expect a few
could give up entirely at that point.  I think that's worse than
floundering around with no documentation at all.

Of course a better solution is for maintainers to update their manuals!

>
> An advantage of separate names (both for the package name and module
> name-space) is that its easier to have both packages installed at the
> same time - the old one to work with while learning the package, the
> new one if other installed packages depend on it. This can still be
> done with package-hiding but its less straight-forward.

With proper .cabal files and dependency bounds this isn't an issue.
If you're working in ghci I think it's the same amount of work either
way, at least with my workflow.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Ivan Lazar Miljenovic]

Jeremy Shaw  writes:

> On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic
>  wrote:
>
>> I recall having a discussion with either you or someone else from the
>> happstack team about why it isn't applicable there, but the QuickCheck
>> problem can be solved in the general case by having its dependency be a
>> compile-time-only option which is disabled by default.
>
> Not really. Cabal likes to recompile things, and it won't remember
> that I compiled another library with quickcheck enabled. So if library
> B depends on library A with quickcheck enabled, it may still happen
> that after I install library A with quickcheck enabled, cabal will
> decide to recompile A again  when building library B, and it will
> build A without quickcheck, causing B to fail...

You of course mean cabal-install, not Cabal when talking about
recompiling things (I know, I'm being picky, but still...).  Also, that
problem is the reason why I recognise that for happstack can't at the
moment have the QuickCheck dependency optional.

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

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Jeremy Shaw]

On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic
 wrote:

> I recall having a discussion with either you or someone else from the
> happstack team about why it isn't applicable there, but the QuickCheck
> problem can be solved in the general case by having its dependency be a
> compile-time-only option which is disabled by default.

Not really. Cabal likes to recompile things, and it won't remember
that I compiled another library with quickcheck enabled. So if library
B depends on library A with quickcheck enabled, it may still happen
that after I install library A with quickcheck enabled, cabal will
decide to recompile A again  when building library B, and it will
build A without quickcheck, causing B to fail...

> However, this is definitely a major problem with parsec, HaXml, etc. and
> probably what I consider the main argument _against_ keeping the same
> name for fgl, though this can occur with packages even with a relatively
> minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API
> change was minor but until all package maintainers upgraded their
> packages to work with 1.7 there would be some inconsistencies).

Right. Minor dependencies have the same issue. The only difference is
that it is generally less work for maintainers to update their code.
So maybe it happens faster/more often. But, we still run into that
issue with happstack as well. We have fixed it by sending patches
upstream. Since they are small patches it is usually easy to get them
created and applied than something like HaXml 1.13 -> 1.19.

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

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Ivan Lazar Miljenovic]

Jeremy Shaw  writes:

> I don't really see this listed on your list, but maybe I missed it.
>
> Happstack has been affected by QuickCheck 1 -> QuickCheck 2, parsec 2
> -> 3, and HaXml 1.13 -> 1.20.
>
> Those packages are common, and people often want to use happstack with
> other libraries that also use those packages. The problem is that if
> we upgrade to the newer versions, then people can't use happstack with
> libraries that use the old version. For example, when we upgrade to
> QuickCheck 2, gitit no longer installed, because some dependency of
> gitit still used (and perhap still does) QuickCheck 1.

My understanding is that this is caused by a limitation in ghc-pkg which
can't tell the difference between re-exposed and only-used-internally
dependencies.

I recall having a discussion with either you or someone else from the
happstack team about why it isn't applicable there, but the QuickCheck
problem can be solved in the general case by having its dependency be a
compile-time-only option which is disabled by default.

However, this is definitely a major problem with parsec, HaXml, etc. and
probably what I consider the main argument _against_ keeping the same
name for fgl, though this can occur with packages even with a relatively
minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API
change was minor but until all package maintainers upgraded their
packages to work with 1.7 there would be some inconsistencies).

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

[Haskell-cafe] strange errors with unix-compat

[Günther Schmidt]

Hello,

when compiling unix-compat I get this:

4 of 4] Compiling System.PosixCompat.Extensions ( 
dist/build/System/PosixCompat/Extensions.hs, 
dist/build/System/PosixCompat/Extensions.o )

cbits/HsUnixCompat.c: In function `unix_major':

cbits/HsUnixCompat.c:4:0:
 warning: implicit declaration of function `major'
cbits/HsUnixCompat.c: In function `unix_minor':

cbits/HsUnixCompat.c:8:0:
 warning: implicit declaration of function `minor'
cbits/HsUnixCompat.c: In function `unix_makedev':

cbits/HsUnixCompat.c:12:0:
 warning: implicit declaration of function `makedev'
/usr/gnu/bin/ar: creatin


and an ghci -package gives me this:

GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package base-3.0.3.1 ... linking ... done.
Loading package unix-2.3.2.0 ... linking ... done.
ghc: 
/home/guenni/.cabal/lib/unix-compat-0.1.2.1/ghc-6.10.4/HSunix-compat-0.1.2.1.o: 
unknown symbol `major'
Loading package unix-compat-0.1.2.1 ... linking ... ghc: unable to load 
package `unix-compat-0.1.2.1'



How can I fix this?

Günther

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

Re: [Haskell-cafe] cabal problem on OS X

[Christopher Done]

I am also experiencing this problem.

I read that the problem was fixed in the latest Cabal-install version.
But I'm not sure, as I tried to install the latest Cabal-install and
got 50 linker errors which I'm not prepared to tackle until the
weekend.

On 8 June 2010 18:21, Gordon J. Uszkay  wrote:
> Did you manage to fix this problem, or are there any updates on it?  I am now 
> having the same issue - presumably due to updating my Mac OS X version, 
> because cabal was working fine before that.  I can't upgrade cabal or install 
> anything either, same reason.
>
> Gordon J. Uszkay
> uszka...@mcmaster.ca
>
>
>
> On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote:
>
>> Bill Atkins  writes:
>>
>>> When I run "cabal update" on my Mac (Snow Leopard, Intel), I get:
>>>
>>> % cabal update
>>> Downloading the latest package list from hackage.haskell.org
>>> cabal: Codec.Compression.Zlib: incompatible zlib version
>>
>> I'm going to randomly guess that the version of the C zlib library that
>> Cabal was indirectly built against is different to the one on your
>> machine.
>>
>> --
>> 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
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Jeremy Shaw]

I don't really see this listed on your list, but maybe I missed it.

Happstack has been affected by QuickCheck 1 -> QuickCheck 2, parsec 2
-> 3, and HaXml 1.13 -> 1.20.

Those packages are common, and people often want to use happstack with
other libraries that also use those packages. The problem is that if
we upgrade to the newer versions, then people can't use happstack with
libraries that use the old version. For example, when we upgrade to
QuickCheck 2, gitit no longer installed, because some dependency of
gitit still used (and perhap still does) QuickCheck 1.

We are now faced with the same problem with HaXml. Do we upgrade to
1.20 and stick with 1.13 for a while? Either way we cause
incompatibilities.

The the cause of QuickCheck, 99% of the time, it would have been ok to
link the app against QC1 and QC2, because no one ever tried to combine
the QC1 tests and the QC2 tests. So, in that cause, making QC1 and QC2
completely different packages would have solved our problem. Duncan C,
also proposed a system whereby we could declare QuickCheck as an
'internal' dependency -- meaning we never export any QC2 functions or
types to the outside word, so it is safe to link against other
versions of QC. That would have worked fine as well, but the proposal
does not seem to have gotten any traction yet. That is unfortunate,
because it seems useful.

In the case of HaXml, things are a bit trickier. It is more likely
that people are going to want to use the HaXml stuff we export with
other libraries that use HaXml, so everyone would have to be using the
same version of HaXml then. At the same time, not very many people
actually use the HaXml stuff in happstack, even if they are using
another library that use HaXml. So, for most people the version
mismatch isn't really an issue. So, like QC, it would actually
probably be better for use if HaXml 1.13 and 1.20 had unique package
names, so we could link against multiple HaXml versions.

Of course, in the case of QC2 and HaXml, the ultimate solution is that
everyone upgrades to the latest, and then the problem goes away. But,
once you start depending on a larger number of packages directly and
indirectly, it does not take very long before you run into someone
that has not updated to the latest, and then you are kind of stuck...

As a maintainer, I have no idea when the right time to switch to HaXml
1.20 is.. and that is an issue. That same would be true of fgl
(though, fortunately, happstack doesn't use that yet). The only
solution I have at the moment, is to upgrade to HaXml 1.20, and then
send patches to any other direct or indirect dependencies of happstack
that use HaXml and get them upgraded as well.. Maybe that is the best
solution.. though it is also a lot of work.

- jeremy

On Tue, Jun 8, 2010 at 10:08 AM, Don Stewart  wrote:
>
> There have been a few cases of major API  / rewrites to famous old
> packages causing problems, including:
>
>    * QuickCheck 1 vs 2
>    * parsec 2 vs 3
>    * OpenGL
>
> a similar opportunity is present with 'fgl', where the new maintainers
> are seeking to improve the code.
>
> Below I try to summarise the pros and cons of calling the new
> rewrite/api 'fgl', in the hope we can identify a path that minimizes
> disruption to users.
>
> 
>
>
> A group of developers is planning to write a new graph library for
> Haskell.
>
>    * They maintain an existing package called 'fgl'.
>    * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/
>    * The new library will have different authors and a different API.
>    * They would like the new library 'fgl'.
>
> It is a controversial step to write a new library and give it the same
> name as an existing, famous library. Let's look at the arguments.
>
> = Reasons to use the new name =
>
>  * The new code  will be better, and should be preferred. Using the name
>   'fgl' will ensure adoption.
>
>  * Rewrites are effective if the name is preserved. E.g. QuickCheck 2.
>
>  * It is the maintainer's right to modify APIs as they see fit.
>
>  * Keeping the old fgl around as a separate package, there is then
>        no real incentive to change/upgrade.
>
>  * Relatively few packages use fgl. So damage is limited.
>
> = Reasons not to use the name =
>
>  * Code that depends on 'fgl' will break.
>       There are 23 direct and 25 indirect dependencies on fgl.
>       
> http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct
>
>  * Doesn't matter if the old fgl is still around. If the new code is
>   better, it will be adopted on its own merits (see e.g.
>   bytestrings vs packedstring, vector vs uvector)
>   Let the market decide if it is better, rather than forcing us.
>
>  * The package has been stable for ~10 years -- why change a stable API?
>    It is already "perfect"
>
>  * The new package really isn't the same package in any sense.
>
>  * Rewrites by new teams damage the b

Re: [Haskell-cafe] Re: package naming policy

[Ivan Lazar Miljenovic]

Jason Dagit  writes:

> On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic <
> ivan.miljeno...@gmail.com> wrote:
>>
>> As part of this, we should consider if we want an official process to do
>> what I've done to kick-off this whole discussion: have a way of telling
>> users "Oj!  New version coming up with heaps of changes!".  Whilst major
>> projects might have their own mailing lists, not all users might be
>> subscribed to them, etc.
>>
>> Should we stick with what I've done and just email haskell@ and
>> haskell-c...@?
>>
>
> Yes, and posting to reddit and having an article on planet haskell about it
> helps too.  There are lots of ways to get the same information and using
> more of them will help you reach your audience.

Well, someone else would have to do the posting on reddit for me; I
waste too much time as-is reading it let alone posting there and getting
involved in the discussions on yet another front! ;-)

I'll do up a blog post in the next day or so to get it on planet though.

-- 
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] Re: package naming policy

[Jason Dagit]

On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> Don Stewart  writes:
> >
> > Yes, my intent here is to produce a set of guidelines for maintainers of
> > important packages, that ensures we balance stability with innovation.
> >
> > We have a great document for what to consider when adding packages to
> > the HP, for example:
> >
> > http://trac.haskell.org/haskell-platform/wiki/AddingPackages
> >
> > But nothing yet for maintainers who want to keep a package moving
> > along.
>
> As part of this, we should consider if we want an official process to do
> what I've done to kick-off this whole discussion: have a way of telling
> users "Oj!  New version coming up with heaps of changes!".  Whilst major
> projects might have their own mailing lists, not all users might be
> subscribed to them, etc.
>
> Should we stick with what I've done and just email haskell@ and
> haskell-c...@?
>

Yes, and posting to reddit and having an article on planet haskell about it
helps too.  There are lots of ways to get the same information and using
more of them will help you reach your audience.

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

Fwd: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Jake McArthur]

Sorry, I hit Reply instead of Reply To All.

-- Forwarded message --
From: Jake McArthur 
Date: Tue, Jun 8, 2010 at 6:16 PM
Subject: Re: [Haskell-cafe] Rewriting a famous library and using the
same name: pros and cons
To: Don Stewart 


Making a new name for an existing package subverts the intended
meaning of major revision numbers. Libraries that break as a result of
a major revision should have had more specific dependencies, and
tutorials that go out of date should also have specified the version
number of the package for which they were intended. It's a package
maintainer's responsibility to respect version number conventions. I
don't believe it is a package maintainer's responsibility to account
for blatant misuse of it.

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

Re: [Haskell-cafe] Re: package naming policy

[Ivan Lazar Miljenovic]

Don Stewart  writes:
>
> Yes, my intent here is to produce a set of guidelines for maintainers of
> important packages, that ensures we balance stability with innovation.
>
> We have a great document for what to consider when adding packages to
> the HP, for example:
>
> http://trac.haskell.org/haskell-platform/wiki/AddingPackages
>
> But nothing yet for maintainers who want to keep a package moving
> along.

As part of this, we should consider if we want an official process to do
what I've done to kick-off this whole discussion: have a way of telling
users "Oj!  New version coming up with heaps of changes!".  Whilst major
projects might have their own mailing lists, not all users might be
subscribed to them, etc.

Should we stick with what I've done and just email haskell@ and
haskell-c...@?

-- 
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] Execution call graph pruning

[Ivan Lazar Miljenovic]

C K Kashyap  writes:

> Hi,
> I have a call grah which contains information of the edges in the following
> format
>
> caller  callee  count   (time spent by the
> caller)
> ===
> foo  bar  10100
> xxx  yyy  2010
> zzz  yyy  1010
>
> (I used pintool pintool.org to generate this call graph)
>
> Now, the problem is that the graph is huge and it take a long to render
> using 'dot' or use any visualizing tool.
> Even if they render, it's too cluttered to be useful.
> I wanted to prune the graph in such a way that I'd have only the edges
> corresponding to the top 10% of the
> time consumers. What would be a good way to do such a thing? Has anyone
> written some utility that I could use?

Well, graphviz [1] lets you parse Dot code, so you could then do a
filter on it (I'm currently working on ways of letting you interact with
the Dot code better).

[1]: http://hackage.haskell.org/package/graphviz

Also, to let you skip a step prof2dot [2] will create the Dot code for you.

[2]: http://hackage.haskell.org/package/prof2dot

-- 
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] Rewriting a famous library and using the same name: pros and cons

[Ivan Lazar Miljenovic]

Gene A  writes:
>
> Oh lord yes...  just call it fgl3 and leave the fgl package alone.
> This is a source based community here... so you take a package that
> has a dependency on another library and you go out and get that to
> cover the dependency and the API is not the same!!!  AND especially if
> that might be the only thing you will ever use that lib for ... and
> you have to stop and rewrite the original.. and as someone else said
> with maybe documentation of that API that is not maybe finished or...
> NO ... At that point the person will probably just DISCARD the compile
> on the lib or program that had the dependency.. rather then put the
> effort in to learn an entire API that doesn't match up..  BAD IDEA!!

So as soon as you write the basics of an API you can never change
it, just extend it to avoid making people have to re-write their code
that uses it?

That road leads down the path of complacency and stagnation IMHO...

-- 
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] Re: [Haskell-cafe] Please check your dependencies on fgl

[Ivan Lazar Miljenovic]

Ian Lynagh  writes:

> On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote:
>
>> A complete rewrite with a new maintainer: fgl-awesome
>
> In 10 years time, we don't want to have
> fgl
> fgl-awesome
> fgl-great
> fgl-joe
> which all do the same thing, and have an unclear relationship to each
> other.

Definitely (though hopefully we wouldn't pick names like "fgl-awesome"
anyway...).

> I think the important question is: Once the new FGL is finished, will
> there be a good reason (other than backwards compatibility) for people
> to use the current FGL?
>
> If yes, then different names should be used. Otherwise, no matter how
> different the API is, keeping the same name is the right thing to do.

And this is why we're going to request the community's input on our API
design: to try and avoid the situation where there's a specific reason
to keep using the old one.

As it stands, the only real advantage that I can think of is that the
new version uses extensions, the old version doesn't (and hence is more
compatible).

> So if there is consensus that the new design is a better fgl, I think it
> ought to keep the name.

Which is what we're trying to build (the consensus, that is).

Don has started a wiki page with the arguments here, and I've already
added my 2c:
http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename

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

[Haskell-cafe] Re: Problems with threading?

[Tom Pledger]

Louis Wasserman  gmail.com> writes:
> 
> While working on the Shootout, I noticed the following benchmarks:
> 
>
http://shootout.alioth.debian.org/u64/program.php?test=chameneosredux&lang=ghc&id=3
>
http://shootout.alioth.debian.org/u64q/program.php?test=chameneosredux&lang=ghc&id=3
[...]
> I'd like to see it improved.
[...]


One difficulty is that the single meeting place is a bottleneck.  The only
parallel activity I can see for the chameneos creatures is standing around in
queues.


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

Re: [Haskell-cafe] HP/Cygwin and Curl

[Malcolm Wallace]

with Cygwin I get

   Linking dist\build\cmu\cmu.exe ...
  C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin 
\windres:

can't open temporary file `\/cca04932.irc': No such file or directory


This sounds very much like a temporary-filename issue.  The reported  
filename's lack of a valid directory specifier looks highly suspicious  
to me.  Are your TEMP, TEMPDIR, TMP, and TMPDIR environment variables  
set? Are their values sensible?  Do you have appropriate permissions  
on the directories they point to?  These are the kinds of thing I  
usually need to check when setting up a new Cygwin build environment.


Admittedly, we do not use cabal on Windows (firewall prevents it from  
working), but the other ghc tools generally seem to work without  
problems for us under Cygwin.


Regards,
Malcolm

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

Re: [Haskell-cafe] HP/Cygwin and Curl

[Claus Reinke]

Your condensed summary was my understanding, but if I try to issue

   Cabal install --reinstall cmu

It works every time from a MSYS shell, but with Cygwin I get


If MSYS works for you, why not stick with it?-)

Cygwin with MinGW tools should work, but it is very easy to mess up
with this setup (configure scripts might not notice that they are on
windows and use the wrong calling convention, Cygwin libraries and
compiler tools might be called accidentally if they are installed, and
so on). Of course, the more people give up and switch to MSYS, the
smaller the chances that such bugs (things that accidentally work when
using MSYS, or with a certain directory layout) get reported and fixed.


   Linking dist\build\cmu\cmu.exe ...
  C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres:
can't open temporary file `\/cca04932.irc': No such file or directory
   cabal.exe: Error: some packages failed to install:
  cmu-1.2 failed during the building phase. The exception was:
  ExitFailure 1

('cmu' is just an example; the same behaviour seems apparent whatever the
package; I see something very similar when I ask GHC to compile hello.hs.)


You could try running 'ghc -v hello.hs' and check the windres command
for oddities. I have no problems building a simple hello world from Cygwin:

   $ uname -a
   CYGWIN_NT-6.1-WOW64 VAIO 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

   $ type ghc
   ghc is hashed (/cygdrive/c/haskell/ghc/ghc-6.12.2.20100522/bin/ghc)

   $ ghc tst.hs

   $ ./main.exe
   Hello, World!


The general answer I seem to have been getting (and responses I have seen
elsewhere top this problem) is 'don't expect the Haskell tools to work 
with

Cygwin'.


That tends to be a self-fulfilling prophesy, similar to 'don't expect the 
Haskell

tools to work on Windows (because so many people rely on unixisms)'. But
the result is that problems do surface more often in this configuration. If 
you

want to investigate, you could file a report on the HP trac.

Claus


At any rate it seems that, for some people at least, the latest version of
the Haskell tools won't work when launched from Cygwin Bash.

Chris

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke
Sent: 08 June 2010 09:02
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl


Thanks Stephen--that was related to my original question, about using
HP with Cygwin. The answer seems to be No!--you must use MSYS (for
real work).


The short version:

- Cygwin provides commandline tools, compilers and libraries
- MSYS provides commandline tools for the MinGW compilers and libraries

You can use the commandline tools from either Cygwin or MSYS, but you need
to compile and link with the compilers and libraries from MinGW.

Cygwin's gcc produces binaries that live in a unix-emulation on top of
windows, and depend on a cygwin dll to act as a translator. MinGW's gcc
produces native windows binaries.

Claus

http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html

___
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] HP/Cygwin and Curl

[Chris Dornan]

Thanks Claus,

Your condensed summary was my understanding, but if I try to issue

Cabal install --reinstall cmu

It works every time from a MSYS shell, but with Cygwin I get

Linking dist\build\cmu\cmu.exe ...
   C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres:
can't open temporary file `\/cca04932.irc': No such file or directory
cabal.exe: Error: some packages failed to install:
   cmu-1.2 failed during the building phase. The exception was:
   ExitFailure 1

('cmu' is just an example; the same behaviour seems apparent whatever the
package; I see something very similar when I ask GHC to compile hello.hs.)

The general answer I seem to have been getting (and responses I have seen
elsewhere top this problem) is 'don't expect the Haskell tools to work with
Cygwin'.

At any rate it seems that, for some people at least, the latest version of
the Haskell tools won't work when launched from Cygwin Bash.

Chris

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke
Sent: 08 June 2010 09:02
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl

> Thanks Stephen--that was related to my original question, about using 
> HP with Cygwin. The answer seems to be No!--you must use MSYS (for 
> real work).

The short version:

- Cygwin provides commandline tools, compilers and libraries
- MSYS provides commandline tools for the MinGW compilers and libraries

You can use the commandline tools from either Cygwin or MSYS, but you need
to compile and link with the compilers and libraries from MinGW.

Cygwin's gcc produces binaries that live in a unix-emulation on top of
windows, and depend on a cygwin dll to act as a translator. MinGW's gcc
produces native windows binaries.

Claus

http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html 

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

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

[Haskell-cafe] Re: Stone age programming for space age hardware?

[Michael Schuerig]

On Tuesday 08 June 2010, Hans van Thiel wrote:
> Now, what Gerard Holzmann told me in the interview, is that NASA is
> very conservative in it's use of software tools. They don't use C++,
> just C, and a well defined version of the GNU C compiler at that.
> The coding standards, which even prohibit the use of C pointers, are
> aimed to keep everything as simple as possible. Just imagine
> hundreds of people working over many years to produce code where any
> error, how trivial it may be, will occur millions of miles away,
> cost hundreds of millions of dollars, and could damage the
> reputation of the company and its future funding.

Perhaps it's just my lack of imagination that was driving my original 
question. I'm just having a hard time imagining how to write reasonably 
interesting algorithms that way.

As I wrote, they might "cheat". It's entirely possible to implement 
dynamic memory on top of fixed-size arrays and use indexes instead of 
pointers. Of course, I have no idea if that's what they do.

Michael

-- 
Michael Schuerig
mailto:mich...@schuerig.de
http://www.schuerig.de/michael/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

[Job Vranish]

Sorry for reopening an old thread, but I thought I'd counter some of the
negative feedback :)


I think this proposal is a great idea!

It seems like this would make working with MPTCs much easier.
When programming, I generally want to only specify the minimum amount of
information to make my code logically unambiguous.
If the code contains enough information to infer the proper instantiation
without the use of an FD, then I shouldn't need to add a FD.
It seems like this would have much more of a "it just works" feel than the
currently alternatives.

Also the MPTC + FDs type errors are a pain. I'm not sure if the type errors
for your proposal would be better, but it would be hard to make them worse.

I do worry about imported instances, (over which we currently have little
control) messing up our code. But this would probably be pretty unusual and
I feel that this is more of a problem with how instances are imported than
with this proposal itself.


Anyway, just my two cents,

- Job


On Thu, May 20, 2010 at 10:34 AM, Carlos Camarao
wrote:

> This message presents, informally, a proposal to solve Haskell's MPTC
> (multi-parameter type class) dilemma. If this informal proposal turns
> out to be acceptable, we (I am a volunteer) can proceed and make a
> concrete proposal.
>
> The proposal has been published in the SBLP'2009 proceedings and is
> available at
> 
> www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdf
>
> The well-known dilemma
> (hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma)
> is that it is generally accepted that MPTCs are very useful, but their
> introduction is thought to require the introduction also of FDs
> (Functional Dependencies) or another mechanism like ATs (Associated
> Types) and FDs are tricky and ATs, somewhat in a similar situation,
> have been defined more recently and there is less experience with its
> use.
>
> In
>
> www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html
> there exists a solution to the termination problem related to the
> introduction of MPTCs in Haskell. In our proposal, neither FDs nor any
> other mechanism like ATs are needed in order to introduce MPTCs in
> Haskell; the only change we have to make is in the ambiguity
> rule. This is explained below. The termination problem is essentially
> ortogonal and can be dealt with, with minor changes, as described in
> the solution presented in the above mentioned (type-class-extensions)
> web page.
>
> Let us review the ambiguity rule used in Haskell-98 and after that the
> ambiguity rule used in GHC. Haskell-98 ambiguity rule (which is
> adequate for Haskell-98's single parameter type classes) is: a type
> C => T is ambiguous iff there is a type variable v that occurs in the
> "context" (constraint set) C but not in the simple (unconstrained)
> type T.
>
> For example: forall a.(Show a, Read a)=>String is ambiguous, because
> "a" occurs in the constraints (Show a,Read a) but not in the simple
> type (String).
>
> In the context of MPTCs, this rule alone is not enough. Consider, for
> example (Example 1):
>
>class F a b where f:: a->b
>class O a where o:: a
> and
> k = f o:: (C a b,O a) => b
>
> Type forall a b. (C a b,O a) => b can be considered to be not
> ambiguos, since overloading resolution can be defined so that
> instantiation of "b" can "determine" that "a" should also be
> instantiated (as FD b|->a does), thus resolving the overloading.
>
> GHC, since at least version 6.8, makes significant progress towards a
> definition of ambiguity in the context of MPTCs; GHC 6.10.3 User’s
> Guide says (section 7.8.1.1):
>
>   "GHC imposes the following restrictions on the constraints in a type
>   signature. Consider the type: forall tv1..tvn (c1, ...,cn) => type. ...
>   Each universally quantified type variable tvi must be reachable from
> type.
>   A type variable a is reachable if it appears in the same constraint as
>   either a type variable free in the type, or another reachable type
> variable.”
>
> For example, type variable "a" in constraint (O a) in the example
> above is reachable, because it appears in (C a b) (the same constraint
> as type variable "b", which occurs in the simple type).
>
> Our proposal is: consider unreachability not as indication of
> ambiguity but as a condition to trigger overloading resolution (in a
> similar way that FDs trigger overloading resolution): when there is at
> least one unreachable variable and overloading is found not to be
> resolved, then we have ambiguity. Overloading is resolved iff there is
> a unique substitution that can be used to specialize the constraint
> set to one, available in the current context, such that the
> specialized constraint does not contain unreachable type variables.
> (A formal definition, with full details, is in the cited SBLP'09 paper.)
>
> Consider, in Example 1, that we have a single instance 

Re: [Haskell-cafe] Re: Stone age programming for space age hardware?

[Hans van Thiel]

That's interesting, writing a DSL that compiles to C. I've actually
inerviewed Gerard Holzamann twice, the first time when he received the
ACM Software System Award in 2002 [1] and in 2008 after he moved to JPL
[2]. What they use to test distributed software is the Process Meta
Language (Promela) which models communication between distributed
processes. Now Spin checks all possible models for deadlock, liveness
etc. You can also use asserts to test conditions, just as in C. 
It also uses LTL (linear temporal logic) to formulate statements like,
"will the railroad crossing always eventually open" and such. Two
articles about Spin are [3] and [4]. Unfortunately, all four are in
Dutch, but, hey, surely somebody here must  be able to read that
language . The articles on Spin contain listings in Promela.
Now, what Gerard Holzmann told me in the interview, is that NASA is very
conservative in it's use of software tools. They don't use C++, just C,
and a well defined version of the GNU C compiler at that. The coding
standards, which even prohibit the use of C pointers, are aimed to keep
everything as simple as possible. Just imagine hundreds of people
working over many years to produce code where any error, how trivial it
may be, will occur millions of miles away, cost hundreds of millions of
dollars, and could damage the reputation of the company and its future
funding. Now, if you can use a DSL to make embedded software absolutely
failsafe, that would certainly grab NASA's attention. But again, they
are very conservative, it seems...

[1] http://muitovar.com/pub/pdf/holzmann.pdf 
[2] http://muitovar.com/pub/pdf/acmaw.pdf 
[3] http://muitovar.com/pub/pdf/spin1.pdf 
[4] http://muitovar.com/pub/pdf/spin2.pdf 


On Tue, 2010-06-08 at 18:27 +0200, Heinrich Apfelmus wrote:
> Michael Schuerig wrote:
> > I was dumbfounded, although I have known all this. I have no personal 
> > experience with either embedded or real time software, but I've been 
> > aware that C still is the most popular language for that purpose and 
> > that coding standards are very restrictive.
> > 
> > The real reason behind my surprise was, that I was wondering how more 
> > modern languages could make inroads into such an environment. Haskell 
> > without recursion and dynamic memory allocation? Hard to imagine.
> 
> I have absolutely no experience with real time system, but if I were
> tasked to write with these coding standards, I would refuse and instead
> create a small DSL in Haskell that compiles to the requested subset of C.
> 
> After all, the question is this: why use C if you don't actually use C?
> The reason is probably that designing/writing a proper DSL is considered
> too error prone, but with today's theorem provers, this should no longer
> be the case.
> 
> 
> Regards,
> Heinrich Apfelmus
> 
> --
> http://apfelmus.nfshost.com
> 
> 


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

Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Daniel Fischer]

On Tuesday 08 June 2010 20:21:54, Gregory Crosswhite wrote:
> Or you just put an upper bound on the versions of the fgl library that
> your program will build against, as you should be doing anyway, and then
> nothing breaks.
>
> Cheers,
> Greg

Right. At least, nothing breaks until the next compiler release makes the 
old library break.
But a new package name wouldn't help with that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Gregory Crosswhite]

Or you just put an upper bound on the versions of the fgl library that your 
program will build against, as you should be doing anyway, and then nothing 
breaks.

Cheers,
Greg

On Jun 8, 2010, at 11:08 AM, Gene A wrote:

> 
> 
> On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart  wrote:
> 
> (... There have been a few cases of major API  / rewrites to famous old
> packages causing problems, including:
> 
>* QuickCheck 1 vs 2
>* parsec 2 vs 3
>* OpenGL
> ...)  
>  
> (...  * No additional breakages are introduced. ...)
> 
> Oh lord yes...  just call it fgl3  and leave the fgl package alone.
> This is a source based community here... so you take a package that
> has a dependency on another library and you go out and get that to cover the
> dependency and the API is not the same!!!  AND especially if that might be 
> the 
> only thing you will ever use that lib for ... and you have to stop and 
> rewrite the
> original.. and as someone else said with maybe documentation of that API that
> is not maybe finished or...  NO ... At that point the person will probably 
> just 
> DISCARD the compile on the lib or program that had the dependency.. rather 
> then put the effort in to learn an entire API that doesn't match up..  
> BAD IDEA!!
> 
> cheers,
> gene 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Haskell-cafe] Re: Stone age programming for space age hardware?

[Michael Schuerig]

On Tuesday 08 June 2010, Heinrich Apfelmus wrote:
> Michael Schuerig wrote:
> > I was dumbfounded, although I have known all this. I have no
> > personal experience with either embedded or real time software,
> > but I've been aware that C still is the most popular language for
> > that purpose and that coding standards are very restrictive.
> > 
> > The real reason behind my surprise was, that I was wondering how
> > more modern languages could make inroads into such an environment.
> > Haskell without recursion and dynamic memory allocation? Hard to
> > imagine.
> 
> I have absolutely no experience with real time system, but if I were
> tasked to write with these coding standards, I would refuse and
> instead create a small DSL in Haskell that compiles to the requested
> subset of C.

That suggestion is similar to the approach taken by "verifiable" 
languages, as Matthias describes it in a parallel reply.

Now, the interesting question is, whether it is possible to define a DSL 
that's expressive enough and still can be translated to a very 
restrictive subset of C. I wouldn't expect the on-board functionality of 
a space probe or rover to be trivial.

I think it would count as cheating if you compile down a DSL to C code 
that only takes a fixed chunk of memory, but then itself manages blocks 
of that memory dynamically.

> After all, the question is this: why use C if you don't actually use
> C? The reason is probably that designing/writing a proper DSL is
> considered too error prone, but with today's theorem provers, this
> should no longer be the case.

As I understood Holzmann in his talk, use of C is a kind of cultural 
heritage at JPL.

BTW, thanks for your recent video on GADTs.

Michael

-- 
Michael Schuerig
mailto:mich...@schuerig.de
http://www.schuerig.de/michael/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Gene A]

On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart  wrote:

>
> (... There have been a few cases of major API  / rewrites to famous old
> packages causing problems, including:
>
>* QuickCheck 1 vs 2
>* parsec 2 vs 3
>* OpenGL
> ...)
>


> (...  * No additional breakages are introduced. ...)
>

Oh lord yes...  just call it fgl3  and leave the fgl package alone.
This is a source based community here... so you take a package that
has a dependency on another library and you go out and get that to cover the
dependency and the API is not the same!!!  AND especially if that might be
the
only thing you will ever use that lib for ... and you have to stop and
rewrite the
original.. and as someone else said with maybe documentation of that API
that
is not maybe finished or...  NO ... At that point the person will probably
just
DISCARD the compile on the lib or program that had the dependency.. rather
then put the effort in to learn an entire API that doesn't match up..
BAD IDEA!!

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

Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?

[Alexander Solla]

On Jun 8, 2010, at 2:38 AM, Alberto G. Corona wrote:


This is`t a manifestation of the Curry-Howard isomorphism?



Yes, basically.

If we rephrase the isomorphism as "a proof is a program, the formula  
it proves is a type for the program" (as Wikipedia states it), we can  
see the connection.  The "characterization" of prelBreak I gave is a  
"type" for prelBreak.  The type is richer than we can express in the  
Haskell type system ("prelbreak accepts a proposition p and a list xs,  
and returns a pair whose first element is the largest prefix of xs for  
which no x satisfies p, and whose second element is the complement of  
the first, taken in xs."), but we can still reason about the richer  
type mathematically, and the Curry-Howard isomorphism applies to it.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Isaac Dupree]

On 06/08/10 11:08, Don Stewart wrote:

Are there any other arguments I'm missing?


Also parsec3 had an issue as an upgrade that it was slower at runtime 
(at least for a few years).  (and some people were using parsec in the 
real world for performance-critical applications.)


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

[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Stephen Tetley]

Hello all

While new libraries develop at pace, their documentation rarely does;
so I'd have to disagree with John's claim that re-naming libraries
makes development by new users harder. I'd argue that having tutorials
not work for later revisions is more confusing than having various
packages doing the same thing. I'd also contend that beginners are
better off lagging behind the cutting edge and using Parsec 2,
QuickCheck 1, Haskore-vintage, as the earlier version all have
comprehensive documentation - Parsec 2 and Haskore have extensive
manual/tutorials, QuickCheck 1 was small enough that the original
QuickCheck paper covered its use.

An advantage of separate names (both for the package name and module
name-space) is that its easier to have both packages installed at the
same time - the old one to work with while learning the package, the
new one if other installed packages depend on it. This can still be
done with package-hiding but its less straight-forward.

Best wishes

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

Re: [Haskell-cafe] Removing alternate items from a list

[Mike Dillon]

OK, here's mine:

f as = [ x | (True,x) <- zip (cycle [True, False]) as ]

-md

begin R J quotation:
> 
> What's the cleanest definition for a function f :: [a] -> [a] that takes a 
> list and returns the same list, with alternate items removed?  e.g., f [0, 1, 
> 2, 3, 4, 5] = [1,3,5]?
> 
> _
> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

> ___
> 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] Removing alternate items from a list

[Yitzchak Gale]

Christopher Done wrote:
> Can't forget fix in a game of code golf!
>
>> (fix $ \f (x:_: xs) -> x : f xs) [1..]
> => [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4...

Ho, good shot! It only works for infinite lists, though:

Prelude> (fix $ \f (x:_: xs) -> x : f xs) [1..10]
[1,3,5,7,9*** Exception: :1:7-30: Non-exhaustive patterns in lambda

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

[Haskell-cafe] Re: Function to find a substring

[Jon Fairbairn]

R J  writes:

> What's an elegant definition of a Haskell function that takes
> two strings and returns "Nothing" in case the first string
> isn't a substring of the first, or "Just i", where i is the
> index number of the position within the first string where the
> second string begins?

f n h = listToMaybe [b | (a,b)<- tails h `zip` [1..], n `isPrefixOf` a]

seems plausible, but how do you define elegant?

-- 
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] Re: haskell.org down?

[Chris Dornan]

I saw on the Reddit page that people urged caution about the costs of
hosting haskell.org commercially. This was a jest wasn't it? ( The cost of
webhosting is absurdly cheap, by almost any standards.)

I would be very happy to help out here but time (where the true costs lie)
is my main concern. If it's still a problem in the new year I will look into
it.

Seriously--this is unnecessary and harmful.

Chris

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Vo Minh Thu
Sent: 08 June 2010 04:04
To: Benjamin L. Russell
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Re: haskell.org down?

2010/6/7 Benjamin L. Russell :
> Ozgur Akgun  writes:
>
>> http://downforeveryoneorjustme.com/www.haskell.org-- Ozgur Akgun
>
> Same problem here since two days ago.
>
> Apparently, the server just went back up.  Anybody know what kept the 
> server down for so long?

http://www.reddit.com/r/haskell/comments/cbkkb/wwwhaskellorg_wiki_mailing_li
st_server_has_been/

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

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

[Haskell-cafe] Re: Stone age programming for space age hardware?

[Heinrich Apfelmus]

Michael Schuerig wrote:
> I was dumbfounded, although I have known all this. I have no personal 
> experience with either embedded or real time software, but I've been 
> aware that C still is the most popular language for that purpose and 
> that coding standards are very restrictive.
> 
> The real reason behind my surprise was, that I was wondering how more 
> modern languages could make inroads into such an environment. Haskell 
> without recursion and dynamic memory allocation? Hard to imagine.

I have absolutely no experience with real time system, but if I were
tasked to write with these coding standards, I would refuse and instead
create a small DSL in Haskell that compiles to the requested subset of C.

After all, the question is this: why use C if you don't actually use C?
The reason is probably that designing/writing a proper DSL is considered
too error prone, but with today's theorem provers, this should no longer
be the case.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

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

Re: [Haskell-cafe] Removing alternate items from a list

[Ozgur Akgun]

>
> It only works for infinite lists, though
>

you wanted it :)

(fix $ \f xs -> case xs of { (x:_: xs) -> x : f xs; _ -> [] }) [1..10]
= [1,3,5,7,9]

here you go :)

2010/6/8 Yitzchak Gale 

> Christopher Done wrote:
> > Can't forget fix in a game of code golf!
> >
> >> (fix $ \f (x:_: xs) -> x : f xs) [1..]
> > => [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4...
>
> Ho, good shot! It only works for infinite lists, though:
>
> Prelude> (fix $ \f (x:_: xs) -> x : f xs) [1..10]
> [1,3,5,7,9*** Exception: :1:7-30: Non-exhaustive patterns in
> lambda
>
> Regards,
> Yitz
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] Removing alternate items from a list

[Jürgen Doser]

El dom, 06-06-2010 a las 14:46 +, R J escribió:
> What's the cleanest definition for a function f :: [a] -> [a] that
> takes a list and returns the same list, with alternate items removed?
>  e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]?

adding another suggestion:

import Data.Either(rights)

f = rights . zipWith ($) (cycle [Left,Right])

Jürgen



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

Re: [Haskell-cafe] Removing alternate items from a list

[Stephen Tetley]

Hello

The regular list functionals - map, zip, foldl, foldr, filter, etc. -
all process the input list at "speed 1" - i.e. one element at a time.

As Ozgur Akgun has shown - consuming the list at "speed 2" gives a
very pleasant implementation - algorithmically:
"consume at speed 2, produce the new list with the first element of
the two and drop the second".

Trying to code an algorithm at "speed 1" with the list functionals
presents a significant hurdle towards clarity of exposition...

Best wishes

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

[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)

[Don Stewart]

jwlato:
> > Great points: I've added them to this wiki page of for and against
> > points:
> >
> >    http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename
> >
> > Please add points as you see fit, and maybe we can come up with a
> > mitigation/change plan.
> >
> 
> Thanks very much; that's a useful page.  It highlights some points I
> hadn't considered, such as when the original author is no longer
> involved with substantial changes to the code.
> 
> Hopefully a productive discussion will follow.  I don't think a
> one-size-fits-all approach is appropriate, but it would be nice if the
> community could come to some common recommendations on this topic.
> 
> Also, to everyone working on fgl: I certainly don't mean to single out
> your work as an example, however I think your contributions to this
> discussion are very helpful as it's a current issue for you.

Yes, my intent here is to produce a set of guidelines for maintainers of
important packages, that ensures we balance stability with innovation.

We have a great document for what to consider when adding packages to
the HP, for example:

http://trac.haskell.org/haskell-platform/wiki/AddingPackages

But nothing yet for maintainers who want to keep a package moving along.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Removing alternate items from a list

[Christopher Done]

On 8 June 2010 15:13, Jürgen Doser  wrote:
> El dom, 06-06-2010 a las 14:46 +, R J escribió:
>> What's the cleanest definition for a function f :: [a] -> [a] that
>> takes a list and returns the same list, with alternate items removed?
>>  e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]?
>
> adding another suggestion:
>
> import Data.Either(rights)
>
> f = rights . zipWith ($) (cycle [Left,Right])

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

Re: [Haskell-cafe] Removing alternate items from a list

[Bill Atkins]

Yes, this was an old draft I accidentally sent out.

My post higher up the thread is correct. :)

On Tuesday, June 8, 2010, Ozgur Akgun  wrote:
> if we add 'a' to the definition of this function, (to make it work), the type 
> of it turns out to be: [a] -> [(a, Bool)]
>
> you might have forgotten the "map fst $" part.
>
> Best,
>
>
> On 8 June 2010 14:51, Bill Atkins  wrote:
>
> f :: [a] -> [a]
> f = filter snd $ zip a (cycle [True, False])
>
> On Monday, June 7, 2010, Ozgur Akgun  wrote:
>> or, since you don't need to give a name to the second element of the list:
>>
>> f :: [a] -> [a]
>> f (x:_:xs) = x : f xsf x = x
>>
>>
>>
>>
>> On 7 June 2010 20:11, Ozgur Akgun  wrote:
>>
>> i think explicit recursion is quite clean?
>>
>>
>> f :: [a] -> [a]f (x:y:zs) = x : f zs
>>
>> f x = x
>>
>>
>> On 7 June 2010 19:42, Thomas Hartman  wrote:
>> maybe this?
>>
>> map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5]
>>
>> 2010/6/6 R J :
>>> What's the cleanest definition for a function f :: [a] -> [a] that takes a
>>> list and returns the same list, with alternate items removed?  e.g., f [0,
>>> 1, 2, 3, 4, 5] = [1,3,5]?
>>>
>>> 
>>> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
>>> Get started.
>>> ___
>>> 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
>>
>>
>> --
>> Ozgur Akgun
>>
>>
>> --
>> Ozgur Akgun
>>
>
>
> --
> Ozgur Akgun
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Updates in the regions library

[Bas van Dijk]

Hi Arie (and others who are interested in the regions library),

I would like to let you know that I'm working on a new version of my
regions package and its reverse dependencies:
regions-monadsfd, regions-monadstf,
safer-file-handles, regional-pointers and usb-safe.

The major change is that I removed the Resource class:

class Resource resource where
data Handle resource ∷ *
open ∷ resource → IO (Handle resource)
close ∷ Handle resource → IO ()

in favor of a much more simple interface, namely:

-- | An 'IO' computation that closes or finalizes a resource. For example
-- 'hClose' or 'free'.
type CloseAction = IO ()

-- | A handle to a 'CloseAction' that allows you to duplicate the action to a
-- parent region using 'dup'.
newtype CloseHandle (r ∷ * → *)

-- | Register the 'CloseAction' in the region. When the region terminates all
-- registered close actions will be perfomed if they're not duplicated to a
-- parent region.
register ∷ MonadIO pr ⇒ CloseAction → RegionT s pr (CloseHandle (RegionT s pr))

Here's an example how to use this new interface from my updated
regional-pointers package:

import qualified Foreign.Marshal.Alloc as FMA

-- | A regional handle to memory. This should provide a safer replacement for
-- Foreign.Ptr.Ptr
data RegionalPtr α (r ∷ * → *) = RegionalPtr (Ptr α) (CloseHandle r)

{-| Allocates the given number of bytes and returns a
regional pointer to them.

This should provide a safer replacement for:
Foreign.Marshal.Alloc.mallocBytes.
-}
mallocBytes ∷ MonadCatchIO pr
⇒ Int
→ RegionT s pr (RegionalPtr α (RegionT s pr))
mallocBytes size = block $ do
 ptr ← liftIO $ FMA.mallocBytes size
 let closeAction = free ptr
 ch ← register closeAction
 return $ RegionalPtr ptr ch

And here's an example from safer-file-handles:

-- | A regional handle to an opened file parameterized by the 'IOMode' in which
-- you opened the file and the region in which it was created.
data RegionalFileHandle ioMode (r ∷ * → *) =
RegionalFileHandle (Handle ioMode) (CloseHandle r)

openFile ∷ MonadCatchIO pr
 ⇒ FilePath
 → IOMode ioMode
 → RegionT s pr
 (RegionalFileHandle ioMode (RegionT s pr))
openFile = openNormal E.openFile

-- | Opens a file in binary mode then yields a regional handle to it. This
-- provides a safer replacement for System.IO.openBinaryFile.
openBinaryFile ∷ MonadCatchIO pr
   ⇒ FilePath
   → IOMode ioMode
   → RegionT s pr
   (RegionalFileHandle ioMode (RegionT s pr))
openBinaryFile = openNormal E.openBinaryFile

openNormal ∷ MonadCatchIO pr
   ⇒ (FilePath → IOMode ioMode → IO (E.Handle ioMode))
   → FilePath
   → IOMode ioMode
   → RegionT s pr
   (RegionalFileHandle ioMode (RegionT s pr))
openNormal open filePath ioMode = block $ do
  h ← liftIO $ open filePath ioMode
  let closeAction = sanitizeIOError $ hClose h
  ch ← register closeAction
  return $ RegionalFileHandle h ch

I haven't released it yet because I need to write some more
documentation. However all the repositories contain the new code:

darcs get http://code.haskell.org/~basvandijk/code/regions
darcs get http://code.haskell.org/~basvandijk/code/regions-monadsfd
darcs get http://code.haskell.org/~basvandijk/code/regions-monadstf
darcs get http://code.haskell.org/~basvandijk/code/regional-pointers
darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles
darcs get http://code.haskell.org/~basvandijk/code/usb-safe

and some examples:

darcs get http://code.haskell.org/~basvandijk/code/usb-safe-examples
darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles-examples
darcs get 
http://code.haskell.org/~basvandijk/code/usb-safe-and-safer-file-handles-examples

Regards,

Bas

On Wed, Jun 2, 2010 at 3:13 PM, Bas van Dijk  wrote:
> On Wed, Jun 2, 2010 at 2:57 PM, Arie Peterson  wrote:
>>> On Wed, Jun 2, 2010 at 2:28 PM, Bas van Dijk 
>> wrote:
 Before answering your questions I would like to make sure I understand
 your Resource type. When I want to create a memory Resource for
 example is the following what you have in mind?

 {-# LANGUAGE Rank2Types #-}

 -- from base:
 import Foreign.Ptr ( Ptr )
 import Foreign.Marshal.Alloc ( mallocBytes, free )

 -- from transformers:
 import Control.Monad.IO.Class ( liftIO )

 -- from MonadCatchIO-transformers:
 import Control.Monad.CatchIO ( MonadCatchIO, bracket )

 newtype Resource cap m = Resource { with :: forall a. (cap -> m a) -> m
 a }

 type Memory m a = Resource (Ptr a) m

 memory :: MonadCatchIO m => Int -> Memory m a
 memory size = Resource $ bracket (liftIO $ mallocBytes size) (liftIO .
 free)
>>
>> Yes, exactly. I also create type aliases for resources providing a
>> specific capability.
>>
>> On Wed, 2 Jun 20

[Haskell-cafe] Execution call graph pruning

[C K Kashyap]

Hi,
I have a call grah which contains information of the edges in the following
format

caller  callee  count   (time spent by the
caller)
===
foo  bar  10100
xxx  yyy  2010
zzz  yyy  1010

(I used pintool pintool.org to generate this call graph)

Now, the problem is that the graph is huge and it take a long to render
using 'dot' or use any visualizing tool.
Even if they render, it's too cluttered to be useful.
I wanted to prune the graph in such a way that I'd have only the edges
corresponding to the top 10% of the
time consumers. What would be a good way to do such a thing? Has anyone
written some utility that I could use?

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

Re: [Haskell-cafe] Function to find a substring

[Jürgen Doser]

El dom, 06-06-2010 a las 15:51 +, R J escribió:
> What's an elegant definition of a Haskell function that takes two
> strings and returns "Nothing" in case the first string isn't a
> substring of the first, or "Just i", where i is the index number of
> the position within the first string where the second string begins?
> 
import Data.List

f a b = findIndex (a `isPrefixOf`) (tails b)


Jürgen

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

Re: [Haskell-cafe] HP/Cygwin and Curl

[Claus Reinke]

Thanks Stephen--that was related to my original question, about using HP
with Cygwin. The answer seems to be No!--you must use MSYS (for real 
work).


The short version:

- Cygwin provides commandline tools, compilers and libraries
- MSYS provides commandline tools for the MinGW compilers and libraries

You can use the commandline tools from either Cygwin or MSYS,
but you need to compile and link with the compilers and libraries
from MinGW.

Cygwin's gcc produces binaries that live in a unix-emulation on top
of windows, and depend on a cygwin dll to act as a translator. MinGW's
gcc produces native windows binaries.

Claus

http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html 


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

Re: [Haskell-cafe] Removing alternate items from a list

[Alexey Levan]

2010/6/6 R J :
> What's the cleanest definition for a function f :: [a] -> [a] that takes a
> list and returns the same list, with alternate items removed?  e.g., f [0,
> 1, 2, 3, 4, 5] = [1,3,5]?

f x = [y | (True, y) <- zip (cycle [False, True]) x]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function to find a substring

[Tillmann Rendel]

Hi,

R J wrote:

What's an elegant definition of a Haskell function that takes two
strings and returns "Nothing" in case the first string isn't a
substring of the first, or "Just i", where i is the index number of
the position within the first string where the second string begins?


The naive algorithm of matching the second string on every position of 
the first string can be implemented as follows.


  import Data.List (findIndex, tails)

  findSubstringIndex text pattern
= findIndex (pattern `isPrefixOf`) (tails text)

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

[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)

[John Lato]

On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart  wrote:
> jwlato:
>> > From: Don Stewart 
>> >
>> > ivan.miljenovic:
>> >> Thomas Bereknyei are currently re-writing fgl (just about completely
>> >> from scratch) and we plan to make an initial release to get feedback
>> >> on the API in the next few weeks.
>> >>
>> >> However, I'm sending this email out now to warn people that I highly
>> >> doubt any code that was written for the current version of fgl
>> >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the
>> >> new version.
>> >
>> > How about you give the library a different name then -- so as not to
>> > break all those programs?
>> >
>> > A complete rewrite with a new maintainer: fgl-awesome
>>
>> I would like to argue against this practice, i.e. re-naming new,
>> incompatible versions of existing packages.  I think it's bad for the
>> following reasons:
>>
>> 1.  It makes development by new users more difficult by fracturing the
>> package-space (the "Which version of QuickCheck should I use?"
>> problem).  Since this is already an acknowledged issue, I think it's
>> better that developers not add to it.
>> 2.  It discourages adoption of the latest version despite any benefits
>> the later version may provide.  This also leads to greater
>> incompatibility between dependent packages.
>> 3.  For packages in the platform, I believe this will create
>> uncertainty about which package(s) should be included with new major
>> releases.
>> 4.  It adds to the maintainer workload as the same person or team will
>> often be responsible for both packages.
>>
>> I do agree that there are legitimate reasons why users may decide to
>> remain with older versions, however I think that in nearly all cases
>> the proper solution is to follow the PVP and for users to include
>> upper dependency bounds in .cabal files.  In particular, for the very
>> common case of compatibility with older code, an upper dependency
>> bound seems like the correct approach.
>>
>> IMHO changing a package name should be for when developers intend to
>> continue development (not just maintenance releases) along both
>> branches.
>
> Great points: I've added them to this wiki page of for and against
> points:
>
>    http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename
>
> Please add points as you see fit, and maybe we can come up with a
> mitigation/change plan.
>

Thanks very much; that's a useful page.  It highlights some points I
hadn't considered, such as when the original author is no longer
involved with substantial changes to the code.

Hopefully a productive discussion will follow.  I don't think a
one-size-fits-all approach is appropriate, but it would be nice if the
community could come to some common recommendations on this topic.

Also, to everyone working on fgl: I certainly don't mean to single out
your work as an example, however I think your contributions to this
discussion are very helpful as it's a current issue for you.

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

[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Don Stewart]

There have been a few cases of major API  / rewrites to famous old
packages causing problems, including:

* QuickCheck 1 vs 2
* parsec 2 vs 3
* OpenGL 

a similar opportunity is present with 'fgl', where the new maintainers
are seeking to improve the code.

Below I try to summarise the pros and cons of calling the new
rewrite/api 'fgl', in the hope we can identify a path that minimizes
disruption to users.




A group of developers is planning to write a new graph library for
Haskell.

* They maintain an existing package called 'fgl'.
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ 
* The new library will have different authors and a different API.
* They would like the new library 'fgl'.

It is a controversial step to write a new library and give it the same
name as an existing, famous library. Let's look at the arguments. 

= Reasons to use the new name =

 * The new code  will be better, and should be preferred. Using the name
   'fgl' will ensure adoption.

 * Rewrites are effective if the name is preserved. E.g. QuickCheck 2.

 * It is the maintainer's right to modify APIs as they see fit.

 * Keeping the old fgl around as a separate package, there is then
no real incentive to change/upgrade.

 * Relatively few packages use fgl. So damage is limited.

= Reasons not to use the name =

 * Code that depends on 'fgl' will break.
   There are 23 direct and 25 indirect dependencies on fgl.
   
http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct

 * Doesn't matter if the old fgl is still around. If the new code is
   better, it will be adopted on its own merits (see e.g.
   bytestrings vs packedstring, vector vs uvector)
   Let the market decide if it is better, rather than forcing us.

 * The package has been stable for ~10 years -- why change a stable API?
It is already "perfect"
 
 * The new package really isn't the same package in any sense.

 * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)

 * No additional breakages are introduced.

 * If you weren't maintainer of 'fgl' this rewrite wouldn't even be
   possible to call 'fgl' -- there's a conflict of interest.

 * Maintaining Haskell98 compatability. Keep it simple. (See
   regex-posix's mistakes here)

 * Distros that support the Haskell Platform will have to keep an old
   version of fgl around for a long time anyway.


Are there any other arguments I'm missing?

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

Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?

[Daniel Fischer]

On Tuesday 08 June 2010 08:33:51, David Virebayre wrote:
> On Sun, Jun 6, 2010 at 5:10 AM, Thomas Hartman  
wrote:
> > Here's two implementations of break, a snappy one from the prelude,
>
> ...
>
> > prelbreak p xs = (takeWhile (not . p) xs,dropWhile (not . p) xs) --
> > fast, more or less as implemented in prelude iiuc
>
> I had a look at the prelude, and I was surprised to see there's 2
> versions, depending on a flag :
>
> #ifdef USE_REPORT_PRELUDE
> break p =  span (not . p)
> #else
> -- HBC version (stolen)
> break _ x...@[]   =  (xs, xs)
> break p xs@(x:xs')
>
>   | p x=  ([],xs)
>   | otherwise  =  let (ys,zs) = break p xs' in (x:ys,zs)
>
> #endif
>
>
> I'm curious why is it so, and which version is compiled in the platform
> or the ghc binaries.
> ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the
> haskell report, but the other version is faster and used by default. )

Aye. I'm not sure whether there's a difference with -O2, but it's 
substantial without optimisations.

>
> David.

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

Re: [Haskell-cafe] Removing alternate items from a list

[aditya siram]

And for a few more lines of codes, you get a more flexible solution:
data Consume = Take | Skip

consumeBy :: [Consume] -> [a] -> [a]
consumeBy []   _  = []
consumeBy _[] = []
consumeBy (tOrS:takesAndSkips) (x:xs) = case tOrS of
  Take -> x : consumeBy takesAndSkips xs
  Skip -> consumeBy
takesAndSkips xs

*Main> consumeBy (cycle [Take,Take,Skip]) [1,2,3,4,5,6]
[1,2,4,5]
*Main> consumeBy (cycle [Take,Take,Take,Skip]) [1,2,3,4,5,6]
[1,2,3,5,6]

-deech

On 6/8/10, Christopher Done  wrote:
> Can't forget fix in a game of code golf!
>
>> (fix $ \f (x:_: xs) -> x : f xs) [1..]
> => [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4...
>
> 2010/6/8 Yitzchak Gale :
>> R J wrote:
>>> What's the cleanest definition for a function f :: [a] -> [a] that takes
>>> a
>>> list and returns the same list, with alternate items removed?  e.g., f
>>> [0,
>>> 1, 2, 3, 4, 5] = [1,3,5]?
>>
>> f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1
>>
>> Regards,
>> Yitz
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cabal problem on OS X

[Gordon J. Uszkay]

Did you manage to fix this problem, or are there any updates on it?  I am now 
having the same issue - presumably due to updating my Mac OS X version, because 
cabal was working fine before that.  I can't upgrade cabal or install anything 
either, same reason.

Gordon J. Uszkay
uszka...@mcmaster.ca



On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote:

> Bill Atkins  writes:
> 
>> When I run "cabal update" on my Mac (Snow Leopard, Intel), I get:
>> 
>> % cabal update
>> Downloading the latest package list from hackage.haskell.org
>> cabal: Codec.Compression.Zlib: incompatible zlib version
> 
> I'm going to randomly guess that the version of the C zlib library that
> Cabal was indirectly built against is different to the one on your
> machine.
> 
> -- 
> 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

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

[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)

[Don Stewart]

jwlato:
> > From: Don Stewart 
> >
> > ivan.miljenovic:
> >> Thomas Bereknyei are currently re-writing fgl (just about completely
> >> from scratch) and we plan to make an initial release to get feedback
> >> on the API in the next few weeks.
> >>
> >> However, I'm sending this email out now to warn people that I highly
> >> doubt any code that was written for the current version of fgl
> >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the
> >> new version.
> >
> > How about you give the library a different name then -- so as not to
> > break all those programs?
> >
> > A complete rewrite with a new maintainer: fgl-awesome
> 
> I would like to argue against this practice, i.e. re-naming new,
> incompatible versions of existing packages.  I think it's bad for the
> following reasons:
> 
> 1.  It makes development by new users more difficult by fracturing the
> package-space (the "Which version of QuickCheck should I use?"
> problem).  Since this is already an acknowledged issue, I think it's
> better that developers not add to it.
> 2.  It discourages adoption of the latest version despite any benefits
> the later version may provide.  This also leads to greater
> incompatibility between dependent packages.
> 3.  For packages in the platform, I believe this will create
> uncertainty about which package(s) should be included with new major
> releases.
> 4.  It adds to the maintainer workload as the same person or team will
> often be responsible for both packages.
> 
> I do agree that there are legitimate reasons why users may decide to
> remain with older versions, however I think that in nearly all cases
> the proper solution is to follow the PVP and for users to include
> upper dependency bounds in .cabal files.  In particular, for the very
> common case of compatibility with older code, an upper dependency
> bound seems like the correct approach.
> 
> IMHO changing a package name should be for when developers intend to
> continue development (not just maintenance releases) along both
> branches.

Great points: I've added them to this wiki page of for and against
points:

http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename

Please add points as you see fit, and maybe we can come up with a
mitigation/change plan.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Function to find a substring

[Paul R]

>>> What's an elegant definition of a Haskell function that takes two strings
>>> and returns "Nothing" in case the first string isn't a substring of the
>>> first, or "Just i", where i is the index number of the position within the
>>> first string where the second string begins?

my quick take, with Maybe and fmap :

substringP :: String -> String -> Maybe Int
substringP _ []  = Nothing
substringP sub str = case isPrefixOf sub str of
  False -> fmap (+1) $ substringP sub (tail str)
  True  -> Just 0

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

[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)

[John Lato]

> From: Don Stewart 
>
> ivan.miljenovic:
>> Thomas Bereknyei are currently re-writing fgl (just about completely
>> from scratch) and we plan to make an initial release to get feedback
>> on the API in the next few weeks.
>>
>> However, I'm sending this email out now to warn people that I highly
>> doubt any code that was written for the current version of fgl
>> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the
>> new version.
>
> How about you give the library a different name then -- so as not to
> break all those programs?
>
> A complete rewrite with a new maintainer: fgl-awesome

I would like to argue against this practice, i.e. re-naming new,
incompatible versions of existing packages.  I think it's bad for the
following reasons:

1.  It makes development by new users more difficult by fracturing the
package-space (the "Which version of QuickCheck should I use?"
problem).  Since this is already an acknowledged issue, I think it's
better that developers not add to it.
2.  It discourages adoption of the latest version despite any benefits
the later version may provide.  This also leads to greater
incompatibility between dependent packages.
3.  For packages in the platform, I believe this will create
uncertainty about which package(s) should be included with new major
releases.
4.  It adds to the maintainer workload as the same person or team will
often be responsible for both packages.

I do agree that there are legitimate reasons why users may decide to
remain with older versions, however I think that in nearly all cases
the proper solution is to follow the PVP and for users to include
upper dependency bounds in .cabal files.  In particular, for the very
common case of compatibility with older code, an upper dependency
bound seems like the correct approach.

IMHO changing a package name should be for when developers intend to
continue development (not just maintenance releases) along both
branches.

My 2 cents, anyway.

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

Re: [Haskell-cafe] Removing alternate items from a list

[Bill Atkins]

f :: [a] -> [a]
f = filter snd $ zip a (cycle [True, False])

On Monday, June 7, 2010, Ozgur Akgun  wrote:
> or, since you don't need to give a name to the second element of the list:
>
> f :: [a] -> [a]
> f (x:_:xs) = x : f xsf x = x
>
>
>
>
> On 7 June 2010 20:11, Ozgur Akgun  wrote:
>
> i think explicit recursion is quite clean?
>
>
> f :: [a] -> [a]f (x:y:zs) = x : f zs
>
> f x = x
>
>
> On 7 June 2010 19:42, Thomas Hartman  wrote:
> maybe this?
>
> map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5]
>
> 2010/6/6 R J :
>> What's the cleanest definition for a function f :: [a] -> [a] that takes a
>> list and returns the same list, with alternate items removed?  e.g., f [0,
>> 1, 2, 3, 4, 5] = [1,3,5]?
>>
>> 
>> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
>> Get started.
>> ___
>> 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
>
>
> --
> Ozgur Akgun
>
>
> --
> Ozgur Akgun
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Removing alternate items from a list

[Ozgur Akgun]

if we add 'a' to the definition of this function, (to make it work), the
type of it turns out to be: [a] -> [(a, Bool)]

you might have forgotten the "map fst $" part.

Best,

On 8 June 2010 14:51, Bill Atkins  wrote:

> f :: [a] -> [a]
> f = filter snd $ zip a (cycle [True, False])
>
> On Monday, June 7, 2010, Ozgur Akgun  wrote:
> > or, since you don't need to give a name to the second element of the
> list:
> >
> > f :: [a] -> [a]
> > f (x:_:xs) = x : f xsf x = x
> >
> >
> >
> >
> > On 7 June 2010 20:11, Ozgur Akgun  wrote:
> >
> > i think explicit recursion is quite clean?
> >
> >
> > f :: [a] -> [a]f (x:y:zs) = x : f zs
> >
> > f x = x
> >
> >
> > On 7 June 2010 19:42, Thomas Hartman  wrote:
> > maybe this?
> >
> > map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5]
> >
> > 2010/6/6 R J :
> >> What's the cleanest definition for a function f :: [a] -> [a] that takes
> a
> >> list and returns the same list, with alternate items removed?  e.g., f
> [0,
> >> 1, 2, 3, 4, 5] = [1,3,5]?
> >>
> >> 
> >> The New Busy is not the old busy. Search, chat and e-mail from your
> inbox.
> >> Get started.
> >> ___
> >> 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
> >
> >
> > --
> > Ozgur Akgun
> >
> >
> > --
> > Ozgur Akgun
> >
>



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

Re[2]: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?

[Bulat Ziganshin]

Hello David,

Tuesday, June 8, 2010, 10:33:51 AM, you wrote:

>  ( my guess is USE_REPORT_PRELUDE compiles functions as defined in
> the haskell report, but the other version is faster and used by default. )

you are right


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?

[Alberto G. Corona]

> This isn`t a manifestation of the Curry-Howard isomorphism?
>
> 2010/6/8 Alexander Solla 
>
>
>> On Jun 7, 2010, at 4:10 PM, Alexander Solla wrote:
>>
>>
>>>  You might note how much like evaluating the function generating the
>>> analysis is.
>>>
>>
>>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function to find a substring

[Yitzchak Gale]

R J wrote:
>> What's an elegant definition of a Haskell function that takes two strings
>> and returns "Nothing" in case the first string isn't a substring of the
>> first, or "Just i", where i is the index number of the position within the
>> first string where the second string begins?

Thomas Hartman wrote:
> If you want to use libs to make your life easier, maybe something
> along these lines?
> Prelude Data.List.Split Safe> ...

True, those are both very nice libraries. It's just about as
easy to do this with the more standard ones, though:

Prelude Data.List Data.Maybe> listToMaybe . map fst . filter (("asdf"
`isPrefixOf`) . snd) . zip [0..] . tails $ "blee blah asdf bloo"
Just 10

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

Re: [Haskell-cafe] Removing alternate items from a list

[Christopher Done]

Can't forget fix in a game of code golf!

> (fix $ \f (x:_: xs) -> x : f xs) [1..]
=> [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4...

2010/6/8 Yitzchak Gale :
> R J wrote:
>> What's the cleanest definition for a function f :: [a] -> [a] that takes a
>> list and returns the same list, with alternate items removed?  e.g., f [0,
>> 1, 2, 3, 4, 5] = [1,3,5]?
>
> f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1
>
> Regards,
> Yitz
> ___
> 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] Fwd: [Gtk2hs-users] Installation problem with cairo.

[Magicloud Magiclouds]

Hi, I cannot subscribe to libraries maillist. So I forward this here.
I cannot install gtk2hs-cairo by cabal using cairo 1.9.6 compiled
myself. Cabal always said that the cairo library/devel files were
missing.

-- Forwarded message --
From: Axel Simon 
Date: Tue, Jun 8, 2010 at 7:15 PM
Subject: Re: [Gtk2hs-users] Installation problem with cairo.
To: Magicloud Magiclouds 
Cc: gtk2hs-users 


Hi again,

it's very difficult for me to say what is happening. Could you ask on
the cabal mailing list to see if anybody there has an idea.

Cheers,
Axel

On 08.06.2010, at 11:01, Magicloud Magiclouds wrote:

> I've tried a little, the error was not thrown out in gtk2hssetup.hs.
> And even I faked a version (1.8.10), it did not work.
>
> On Tue, Jun 8, 2010 at 3:47 PM, Axel Simon  wrote:
>>
>> Hi,
>>
>> On Jun 8, 2010, at 9:21, Magicloud Magiclouds wrote:
>>
>>> Yes, seems like so.
>>> Here is the output:
>>>
>>> # /usr/bin/pkg-config --modversion cairo-pdf
>>> 1.9.6
>>> # /usr/bin/pkg-config --modversion cairo-ps
>>> 1.9.6
>>> # /usr/bin/pkg-config --modversion cairo-svg
>>> 1.9.6
>>> # /usr/bin/pkg-config --modversion cairo
>>> 1.9.6
>>>
>>
>> Oh dear.
>>
>> Since cabal manages once to get the correct version and fails later on, I
>> assume it's the magic Duncan added to out Gtk2HsSetup.hs file that requests
>> the package version again. If you look for
>>
>> --FIXME: Cabal should tell us the selected pkg-config package versions in
>> the
>> --       LocalBuildInfo or equivalent.
>> --       In the mean time, ask pkg-config again.
>>
>> in the cabal file and try to add some debugging output then maybe you can
>> find out more.
>>
>> I suspect that either the LocalBuildInfo or the PackageDescription value is
>> not the most up-to-date one but some default value that lack some path or
>> some such.
>>
>> cheers,
>> Axel
>>
>>> On Tue, Jun 8, 2010 at 2:56 PM, Axel Simon  wrote:

 Hi,

 On Jun 8, 2010, at 8:54, Magicloud Magiclouds wrote:

> /usr/bin/pkg-config --modversion cairo
> setup: Missing dependency on a foreign library:
> * Missing C library: cairo
> This problem can usually be solved by installing the system package that
> provides this library (you may need the "-dev" version). If the library
> is
> already installed but in a non-standard location then you can use the
> flags
> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.

 well, what's the output of

> /usr/bin/pkg-config --modversion cairo

 ? Maybe cabal fails to parse the version for some reason.

 Axel


>>>
>>>
>>>
>>> --
>>> 竹密岂妨流水过
>>> 山高哪阻野云飞
>>
>>
>
>
>
> --
> 竹密岂妨流水过
> 山高哪阻野云飞




-- 
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] PDF generation?

[Leon Smith]

The fonts aren't rasterized,  but PDFs that were converted from PS
tend to look awful in almost any PDF viewer other than Adobe's Acrobat
Reader.  Fonts look especially bad.

I don't know exactly what the problem is, but my experience is that
you are best off generating PDF directly,  and using Acrobat Reader on
any document that looks bad otherwise.   Not to mention that PDF has a
document model and supports things such as hyperlinks,  which
Postscript does not,  which is another reason to avoid PostScript.

Best,
Leon


On Tue, Jun 1, 2010 at 2:45 PM, Yitzchak Gale  wrote:
> I wrote:
>>> I have often generated PostScript from Haskell...
>>> Then you convert the PS to PDF using any of the nice
>>> utilities around for that
>
> Pierre-Etienne Meunier wrote:
>> Isn't there a problem with non-type 1 vectorial fonts being
>> rasterized during this conversion ?
>
> No.
>
> PDF is just a simplified, compressed encoding of PostScript.
> Unless there is some special reason to do so, why would
> a conversion utility go to the trouble of rasterizing fonts
> instead of just copying them in?
>
> Perhaps something like ImageMagick might do that; its
> internal format is a raster.
>
> Regards,
> Yitz
> ___
> 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] Removing alternate items from a list

[Yitzchak Gale]

R J wrote:
> What's the cleanest definition for a function f :: [a] -> [a] that takes a
> list and returns the same list, with alternate items removed?  e.g., f [0,
> 1, 2, 3, 4, 5] = [1,3,5]?

f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1

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

Re: [Haskell-cafe] Stone age programming for space age hardware?

[Matthias Guedemann]

Hi,

> The real reason behind my surprise was, that I was wondering how more 
> modern languages could make inroads into such an environment. Haskell 
> without recursion and dynamic memory allocation? Hard to imagine.

for some safety critical applications that require certification, SCADE with the
underlying Lustre language is used. It has formal semantics and some properties
can be checked with automatic verification (up to linear arithmetic).

The Lustre dataflow programs are then transformed to C (or Ada), by compiling to
automata and representing those in C. This transformation is realized in Ocaml
afaik. I think these kind of transformations, maybe specifying an embedded DSL
instead of using a language like Lustre resulting in C with static bounds
etc. could be a way to use Haskell. But anything using dynamic memory
allocation, GC etc. is dangerous for real-time bounds. These programs also often
run on old "outdated", but reliable HW for which mainly C compilers exist. The 
used standards only allow a certain set of programming languages (or subsets of
these languages) and you even have to use "proved and tested" compilers and
tools. 

> I have a hunch that the real restrictions of this kind of software are 
> not concerned with fixed memory, iterations, whatever, but rather with 
> guaranteed bounds. If that is indeed the case, how feasible would it be 
> to prove relevant properties for systems programmed in Haskell?

I think proving the correct transformation of some input language to static C
using Haskell is possible. Functional languages like Haskell or Ocaml in the
case of SCADE are well suited to this, due to lack of loops, side effects etc.

I think "atom" is such a DSL embedded into Haskell that can generate code for
real-time systems.

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

RE: [Haskell-cafe] HP/Cygwin and Curl

[Chris Dornan]

Thanks very much: I didn't know about this resource.

I do appreciate all of the hard work everyone has put in and I want to
contribute myself, especially in 2011 (I am fully committed until then). For
the moment the best contribution I can make is to report the problems I am
having.

The above wiki page is (of course) too vague about how Cygwin and MSYS can
be used. Cygwin is a much better supported product and a much easier way of
getting hold of many Unixy things (like X11). AFAIK MSYS doesn't have a
proper installer at the moment.

It would be nice to know how Cygwin can be used with HP. If the answer is
not at all (for serious work) then can we say this very prominently on HP
Windows page. How about linking the HP-Windows page to the Wiki article on
Haskell for Windows?

A FAQ for HP would also surely be useful.

If others agree these would be useful and they haven't been when I will pick
them up, but first, are these a good idea?

My feeling is that the ramp onto Haskell is far steeper than it needs to be
considering the fundamental excellence of the parts.

Chris


-Original Message-
From: Henk-Jan van Tuyl [mailto:hjgt...@chello.nl] 
Sent: 07 June 2010 22:28
To: Chris Dornan
Cc: Haskell-Cafe@haskell.org
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl

On Mon, 07 Jun 2010 21:44:13 +0200, Chris Dornan 
wrote:

> Thanks ever so much for your clear answer. I have no problem at all 
> with using MSYS to build libraries that link to libraries built in 
> Windows land--this seems entirely reasonable.
>
> Is this written down somewhere? I mean I really would like to RTFM! 
> :-)
>

Some information can be found at:
   http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation
(improvements are welcome)

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

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