Re: [Haskell-cafe] type error using ghc 6.10.1, not in previous versions

[Anish Muttreja]

On Mon, Jan 12, 2009 at 07:14:36PM -0800, Tim Bauer wrote:
> Hi all. Under I have some old code that broke under ghc 6.10.1.
> Under (6.6.1), 6.8.1 (and I think 6.8.2), this compiles.
>
> import Prelude hiding(catch)
> import Control.Concurrent
> import Control.Exception(catch,throw,evaluate)
>
> async :: IO a -> IO (MVar a)
> async ioa = do
> mVar <- newEmptyMVar
> forkIO $ catch (ioa >>= putMVar mVar) (putMVar mVar . throw)
> return mVar

>
>
> Under 6.10. I now get a type error.
>
> TypeError.hs:13:55:
> Ambiguous type variable `e' in the constraint:
>   `GHC.Exception.Exception e'
> arising from a use of `throw' at TypeError.hs:13:55-59
> Probable fix: add a type signature that fixes these type variable(s)
>
> Prelude> :t catch
> catch :: IO a -> (IOError -> IO a) -> IO a
> Prelude> :t Control.Exception.catch
> Control.Exception.catch :: (GHC.Exception.Exception e) =>
>IO a -> (e -> IO a) -> IO a
>
> What changed that causes this to break between 6.8 and 6.10?
> In fact, I don't even see the type error (the message is
> of little help). The function throw returns an `a', so it
> should unify with the required type for the handler.
>

Hi Tim,
There were messages about this on the list before, I believe. 
>From ghc 6.10.1 release notes, what changed is this
"Control.Exception now uses extensible  exceptions. The old style of 
exceptions are still available in Control.OldException, but we expect to 
remove them in a future release. "
http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html

Providing a type signature for the argument of throw ought to fix it.
forkIO $ catch (ioa >>= putMVar mVar) (\e  -> (putMVar mVar . throw) (e 
:: IOException) )

I don't really understand what extensible exceptions are, just 
that providing a type signature makes the compiler happy. This 
www.haskell.org/~simonmar/papers/ext-exceptions.pdf might provide the 
explanation.

Hope that helps.

Anish


> I tried simplifying the problematic line to:
> forkIO $ catch (ioa >>= putMVar mVar) (error "boom")
> (error "boom") should also unify with anything.



>
> Can anyone suggest other things I can try and perhaps what
> is going on?
> Thanks,
> - Tim
> ___
> 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] ANN: bytestring-trie 0.1.4

[wren ng thornton]

Don Stewart wrote:

Do you have any benchmarks comparing dictionaries against Map ByteString
Int, or Map String Int?


I haven't personally run them, but Mark Wotton has compared 
[(ByteString,Int)] vs (Map ByteString Int) vs (Trie Int) version 0.1.1 
or 0.1.2 and using data from /usr/share/dict/words:



9:22 ~/projects/current/MapBench % ghc --make  Test.hs
../../Microbench.hs && ./Test
[1 of 2] Compiling Microbench   ( ../../Microbench.hs, 
../../Microbench.o )

[2 of 2] Compiling Main ( Test.hs, Test.o )
Linking Test ...
* alist lookup:
  160.641ns per iteration / 6225.07 per second.
* map lookup:
  0.881ns per iteration / 1135623.22 per second.
* Trie lookup:
  0.243ns per iteration / 4116930.41 per second.


The benchmarking code requires hacking microbench to use Integers 
instead of Ints, to avoid counter overflow. I haven't yet worked the 
benchmarking code into the Darcs repo, but it's available to those 
interested. I'll add it to the repo soon.


The cost of inserting elements is higher for Trie than Map (I don't have 
the numbers). One possible reason for this is that the generic alterBy 
doesn't know whether it's inserting or deleting, so it uses smart 
constructors along the spine which adds the cost of consistency checks. 
I've planned to add a dedicated implementation for insertBy (or 
modifyBy, or some such name) in order to test this hypothesis.


The cost of merging is still unknown, but big-endian patricia trees have 
better asymptotic complexity than the balanced trees used by Map, so 
Trie is probably better there too.


Another improvement in the works is a smarter algorithm for splitting 
strings. Once it's in place, this should speed up all three of the main 
algorithms.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: json-0.4.1

[Sigbjorn Finne]

Hi,

a new release of the 'json' package is now available via hackage,
version 0.4.1

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json

[no claims that it represents rocket science, but a number of downstream
codebases depend on this package for their operation, hence the
announcement here.]

New in this release is a generic JSON encoder contributed by Lennart
Augustsson (Text.JSON.Generic ; thanks Lennart!) along with a number
of other, smaller changes (including changes to the default encoding
for constructors and prelude types - no longer down-cased; see release
notes for more.)

Enjoy
--sigbjorn

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

[Haskell-cafe] type error using ghc 6.10.1, not in previous versions

[Tim Bauer]

Hi all. Under I have some old code that broke under ghc 6.10.1.
Under (6.6.1), 6.8.1 (and I think 6.8.2), this compiles.

import Prelude hiding(catch)
import Control.Concurrent
import Control.Exception(catch,throw,evaluate)

async :: IO a -> IO (MVar a)
async ioa = do
mVar <- newEmptyMVar
forkIO $ catch (ioa >>= putMVar mVar) (putMVar mVar . throw)
return mVar


Under 6.10. I now get a type error.

TypeError.hs:13:55:
Ambiguous type variable `e' in the constraint:
  `GHC.Exception.Exception e'
arising from a use of `throw' at TypeError.hs:13:55-59
Probable fix: add a type signature that fixes these type variable(s)

Prelude> :t catch
catch :: IO a -> (IOError -> IO a) -> IO a
Prelude> :t Control.Exception.catch
Control.Exception.catch :: (GHC.Exception.Exception e) =>
   IO a -> (e -> IO a) -> IO a

What changed that causes this to break between 6.8 and 6.10?
In fact, I don't even see the type error (the message is
of little help). The function throw returns an `a', so it
should unify with the required type for the handler.

I tried simplifying the problematic line to:
forkIO $ catch (ioa >>= putMVar mVar) (error "boom")
(error "boom") should also unify with anything.

Can anyone suggest other things I can try and perhaps what
is going on?
Thanks,
- Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multiple State Monads

[David Menendez]

On Mon, Jan 12, 2009 at 8:34 PM, Phil  wrote:
> Thanks Minh - I've updated my code as you suggested.  This looks better than
> my first attempt!
>
> Is it possible to clean this up any more?  I find:
>
> ( (), (Double, Word64) )
>
> a bit odd syntactically, although I understand this is just to fit the type
> to the State c'tor so that we don't have to write our own Monad longhand.

If you have a function which transforms the state, you can lift it
into the state monad using "modify".

> evolveUnderlying :: (Double, Word64) -> (Double, Word64)
> evolveUnderlying (stock, state) = ( newStock, newState )
>  where
>newState = ranq1Increment state
>newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
> vol*sqrt(timeStep)*normalFromRngState(state) ) )
>
> getEvolution :: State (Double, Word64) ()
> getEvolution = modify evolveUnderlying

Now, I don't know the full context of what you're doing, but the
example you posted isn't really gaining anything from the state monad.
Specifically,

  execState (replicateM_ n (modify f))
= execState (modify f >> modify f >> ... >> modify f)
= execState (modify (f . f . ... . f))
= f . f . ... . f

So you could just write something along these lines,

> mcSimulate :: Double -> Double -> Word64 -> [Double]
> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate
> startStock endTime newSeedForSeed
>  where
>expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) 
> !! truncate (endTime/timeStep)
>newSeedForSeed = seedForSeed + 246524


Coming back to your original question, it is possible to work with
nested state monad transformers. The trick is to use "lift" to make
sure you are working with the appropriate state.

get :: StateT s1 (State s2) s1
put :: s1 -> StateT s1 (State s2) ()

lift get :: StateT s1 (State s2) s2
lift put :: s2 -> StateT s1 (State s2) ()

A more general piece of advice is to try breaking things into smaller
pieces. For example:

getRanq1 :: MonadState Word64 m => m Word64
getRanq1 = do
seed <- get
put (ranq1Increment seed)
return seed

getEvolution :: StateT Double (State Word64) ()
getEvolution = do
seed <- lift getRanq1
modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep
+ ( vol*sqrt(timeStep)*normalFromRngState(seed) ) )


-- 
Dave Menendez 

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

Re: [Haskell-cafe] Multiple State Monads

[Luke Palmer]

On Mon, Jan 12, 2009 at 6:34 PM, Phil  wrote:

> -- Monad Implementation
>
> evolveUnderlying :: (Double, Word64) -> ( (), (Double, Word64) )
> evolveUnderlying (stock, state) = ( (), ( newStock, newState ) )
>   where
>newState = ranq1Increment state
>newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
> vol*sqrt(timeStep)*normalFromRngState(state) ) )
>

How about:

evolveUnderlying :: (Double, Word64) -> (Double, Word64)
evolveUnderlying (stock, state) = (newStock, newState)
  where ...

getEvolution = modify evolveUnderlying

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

Re: [Haskell-cafe] Functions with generic return types

[Luke Palmer]

On Mon, Jan 12, 2009 at 5:56 PM, Stephen Hicks  wrote:

> -- This instance definition is broken...
> instance (Monad m,Pick (a,b) c) => Pick (m a,m b) (m c) where
>pick (ma,mb) = do { a <- ma; b <- mb; return $ pick (a,b) }


First, and I know these types of comments are generally unwanted, but I
recommend you *not do this*.  You are only making pain for yourself later.
Haskell is not good at this type of ad-hoc polymorphism (partially because
it does not play well with inference).  I.e. whyever you think you need this
machinery, I suggest you spend some time rethinking why this is really
necessary.

Okay, now to explain this instance.

An instance Pick (a,b) c is just a function (a,b) -> c.  So this instance
reduces to the possibility of writing a function:

monadify :: ((a,b) -> c) -> ((m a, m b) -> m c)

Which is only implementable by executing both actions m a and m b (because
you need both an a and a b to pass to c).  Consider what would happen if a
pick function looked at the contents of its argument?  e.g. maybe someone
writes:

instance Pick (Int,Int) Int where
pick (x,y) = min x y

Then you would have to know the actual values to decide what to return, thus
both actions must be executed.

One thing I always like to do when I'm writing typeclasses is write the
proof term library first (i.e. explicit dictionary passing) and then start
turning those into typeclasses.  This practice helps to weed out impossible
ideas (eg. if you can't do what you want by explicitly passing dictionaries,
how is the compiler going to infer the dictionaries for you?), and also to
make more transparent what terms are being constructed.

As an example, you might start:

type PickD a b = a -> b

leftTuple :: PickD (a,b) a
leftTuple = fst
rightTuple :: PickD (a,b) b
rightTuple = snd
func :: PickD (a,b) c -> PickD (d -> a, d -> b) (d -> c)
func p (f,g) x = p (f x, g x)

...

And do this for each of your proposed instances.  Then do an example use
case, using these functions explicitly, and try to envisage an algorithm
which might pick the functions for you.  Then it will be much more obvious
if it is possible to typeclassify these, and if so, how.

Luke


>
> foo :: Pick (String,Int) t => String -> t
> foo = pick (id :: String -> String, length :: String -> Int)
>
> toStr :: String -> IO String
> toStr s = putStrLn "str" >> return s
> toInt :: String -> IO Int
> toInt s = putStrLn "int" >> return (length s)
>
> bar :: Pick (String,Int) t => String -> IO t
> bar = pick (toStr,toInt)
> ___
> 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] Multiple State Monads

[Phil]

Thanks Minh - I've updated my code as you suggested.  This looks better than
my first attempt!

Is it possible to clean this up any more?  I find:

( (), (Double, Word64) )

a bit odd syntactically, although I understand this is just to fit the type
to the State c'tor so that we don't have to write our own Monad longhand.  I
guess given that (), as I understand, is just like 'void' in C, it should
not affect program performance, and the fact that I'm using replicateM_
means that the result is being ignored for all but my last iteration.

As an exercise I assume I could have approached the problem using the StateT
transformer, although for the purposes below carrying two states in a tuple
is probably clearer and more performant?

Thanks again,

Phil.

mcSimulate :: Double -> Double -> Word64 -> [Double]
mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate
startStock endTime newSeedForSeed
  where
expiryStock =  execState ( do replicateM_ (truncate(endTime/timeStep)-1)
getEvolution; getEvolution )
   $ (startStock,ranq1Init seedForSeed)
newSeedForSeed = seedForSeed + 246524


-- Monad Implementation

evolveUnderlying :: (Double, Word64) -> ( (), (Double, Word64) )
evolveUnderlying (stock, state) = ( (), ( newStock, newState ) )
  where
newState = ranq1Increment state
newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
vol*sqrt(timeStep)*normalFromRngState(state) ) )

getEvolution :: State (Double, Word64) ()
getEvolution = State evolveUnderlying


On 12/01/2009 20:49, "minh thu"  wrote:

> 2009/1/12 Phil :
>> Hi,
>> 
>> I've been reading the Monads aren't evil posts with interest ­ I'm a 2nd
>> week Haskell newbie and I'm doing my best to use them where (I hope) it is
>> appropriate.  Typically I'm writing my code out without using Monads
>> (normally using list recursion), and then when I get them working, I delve
>> into the Monad world This has been going well so far with a bit of help
>> from you guys, but I've hit a snag.
>> 
>> In the code below I'm using a state Monad (getEvolution), but unlike simpler
>> cases I'm passing around two items of state, and one of these states is also
>> ultimately a result ­ although I don't care about the result until I reach
>> an end state.  My implementation is a bit ugly to say the least and clearly
>> I'm forcing round pegs into square holes here ­ reading a bit online I get
>> the impression that I can solve the two-state issue using Monad
>> Transformers, by  wrapping a StateT around a regular State object (or even
>> two StateT Monads around an Identity Monad??).  I think I understand the
>> theory here, but any attempt to implement it leads to a horrible mess that
>> typically doesn't compile.  The other problem of having a state that is also
>> a result, I'm sure what to do about this.
>> 
>> Was wondering if anyone could give me a push in the right direction ­ how
>> can I rework my state monad so that it looks less wildly.
>> 
>> Many thanks,
>> 
>> Phil.
>> 
>> mcSimulate :: Double -> Double -> Word64 -> [Double]
>> mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate
>> startStock endTime newSeedForSeed
>>   where
>> expiryStock =  evalState ( do replicateM_ (truncate(endTime/timeStep)-1)
>> getEvolution; getEvolution )
>>$ (startStock,ranq1Init seedForSeed)
>> newSeedForSeed = seedForSeed + 246524
>> 
>> discount :: Double -> Double -> Double -> Double
>> discount stock r t = stock * exp (-r)*t
>> 
>> payOff :: Double -> Double -> Double
>> payOff strike stock | (stock - strike) > 0 = stock - strike
>> | otherwise = 0
>> 
>> -- Monad Implementation
>> 
>> -- Yuk!
>> evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) )
>> evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) )
>>   where
>> newState = ranq1Increment state
>> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
>> vol*sqrt(timeStep)*normalFromRngState(state) ) )
>> 
>> getEvolution :: State (Double, Word64) Double
>> getEvolution = State evolveUnderlying
> 
> Hi,
> 
> the evolveUnderlying can simply manipulate the state, so you can
> 
> do evolveUnderlying -- state (not your state, but the tuple) changes here
>r <- gets fst -- query the state for the first element of the tuple
>return r -- simply return what you want
> 
> Note that if you want to combine your state and the stock, you simply end
> with a new kind of state : the tuple (thus, no need to compose two State)
> 
> Note also, since evolveUnderlying only manipulates the internal state of the
> State monad, it returns ().
> 
> Depending on how you want to structure your code, you can also use execState
> instead of evalState : it returns the state on which you can use fst.
> 
> hope it helps,
> Thu

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

[Haskell-cafe] Functions with generic return types

[Stephen Hicks]

Hi,

I'm trying to write a small module for conveniently writing functions
that can return any of a finite number of types.  That is, I'd like to
be able to write something like
  foo :: StringOrInt t => String -> IO t
This is pretty easy to do if I hard-code the classes as above, but I
run into difficulties making it more general.  In particular, it's
convenient to use incoherent instances so that I can insert the
polymorphism at whatever level I choose (see the third instance
declaration below, as well as the function foo).  But when I try to
make this work for monads, it fails - that is, my function bar (below)
always prints both "str" and "int" because I can't make it lazy enough
- in order to get even a thunk in the non-monadic type, it seems like
the side effect has to happen (unsafeInterleaveIO + seq would sort of
fix this here, but not generally), whereas the type alone should be
sufficient in selecting which monad needs to be evaluated.

I'm having a hard time explaining this abstractly, but I think the
following concrete code explains pretty clearly what I'm trying to do,
and I would appreciate any comments or suggestions for either a better
way to go about this, or something already written that achieves
something similar?

Thanks,
steve



{-# LANGUAGE TypeSynonymInstances, MultiParamTypeClasses,
FlexibleInstances, FlexibleContexts, IncoherentInstances #-}

class Pick c a where pick :: c -> a

instance Pick (a,b) a where pick = fst
instance Pick (a,b) b where pick = snd

instance Pick (a,b) c => Pick (d -> a, d -> b) (d -> c) where
pick (a,b) d = pick (a d,b d)

-- This instance definition is broken...
instance (Monad m,Pick (a,b) c) => Pick (m a,m b) (m c) where
pick (ma,mb) = do { a <- ma; b <- mb; return $ pick (a,b) }

foo :: Pick (String,Int) t => String -> t
foo = pick (id :: String -> String, length :: String -> Int)

toStr :: String -> IO String
toStr s = putStrLn "str" >> return s
toInt :: String -> IO Int
toInt s = putStrLn "int" >> return (length s)

bar :: Pick (String,Int) t => String -> IO t
bar = pick (toStr,toInt)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for Haskellers on Windows

[John Goerzen]

Andrew Coppin wrote:
> Günther Schmidt wrote:
>> Hi Bulat,
>>
>> I do :), but I was amazed that there was no response to a post with, 
>> what I thought, would be a rather common problem for an application 
>> developer. That post was about writing to an MS-Access database via 
>> HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself 
>> it turned out that he doesn't use Windows either and thus can't help.
>>
>> Thus my cry for help explicitly to Haskellers on Windows.
> 
> If you managed to get HDBC-ODBC to compile on Windows in the first 
> place, you got further than me...

Can you describe exactly what the problem you're having is?

> 
> It's a pitty that Windows receives so little support, but I guess if 
> nobody has a Windows box to test with, there's not much you can do about it.
> 
> ___
> 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: System.CPUTime and picoseconds

[Peter Verswyvelen]

I just tried getCPUTime on Windows and it seems to tick really slow, about
10 times per second or so. Actually it changes every 1560010
picoseconds, so about 15600 microseconds, which is indeed the interval at
which Windows updates its "tick" count.
So anyway a lot of room to go to the picosecond resolution :)

But, is this intended behavior? How does it perform on Linux? Should it
behave the same on all platforms?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unfoldr [ANN: HLint 1.2]

[Robin Green]

On Mon, 12 Jan 2009 21:04:35 +0100 (CET)
Henning Thielemann  wrote:

> 
> On Mon, 12 Jan 2009, Andrew Coppin wrote:
> 
> > Off the top of my head, try this:
> >
> > convert b 0 = []
> > convert b n = n `mod` b : convert b (n `div` b)
> >
> > (Takes a number and yields the radix-B representation of it.
> > Backwards.)
> >
> > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div`
> > b) else Nothing)
> 
> I have the nice function 'toMaybe' which simplifies this to:
>unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b))

I would use the more general idiom:

 unfoldr (\n -> guard (n > 0) >> return (n `mod` b, n `div` b))

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

Re: [Haskell-cafe] Gtk2Hs on Windows for GHC 6.10.1

[Duncan Coutts]

On Tue, 2009-01-13 at 00:09 +0100, Peter Verswyvelen wrote:
> Gtk2Hs 0.9.13 has an annoying bug on Windows that makes it impossible
> to run via GHCi.
> 
> 
> So to see if the latest development version works better, I tried to
> build it on Windows using GHC 6.10.1, but I failed to do so with both
> MSYS and Cygwin.
> 
> 
> Does anybody know how to build it on Windows?

If the instructions on the gtk2hs website do not help:

http://haskell.org/gtk2hs/archives/category/faqs/
http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-windows/

then the best place to ask is on the gtk2hs users mailing list:
http://haskell.org/gtk2hs/development/#mailing_lists


Duncan


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

Re: [Haskell-cafe] Data analysis with Haskell

[Luke Palmer]

On Mon, Jan 12, 2009 at 2:16 PM, Daniel Kraft  wrote:

> This was probably my fault at that time, because I surely did something
> completely wrong for the Haskell style.  However, I fear I could run into
> problems like that in the new project, too.  So I want to ask for your
> opinions, do you think Haskell is the right language to do data analysis of
> this kind?  And do you think it is hard for still beginner Haskell
> programmer to get this right so Haskell does not use up a lot of memory for
> thunks or list-overhead or things like that?


Haskell's memory performance *can* be quite subtle.

Here's my opinion though:  avoiding a language is a terrible way to learn
it.  If you want to learn Haskell, do your project in Haskell.

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

Re: [Haskell-cafe] Monads aren't evil? I think they are.

[Philippa Cowderoy]

On Sun, 2009-01-11 at 10:44 +0100, Apfelmus, Heinrich wrote:
> Ertugrul Soeylemez wrote:
> > Let me tell you that usually 90% of my code is
> > monadic and there is really nothing wrong with that.  I use especially
> > State monads and StateT transformers very often, because they are
> > convenient and are just a clean combinator frontend to what you would do
> > manually without them:  passing state.
> 
> The insistence on avoiding monads by experienced Haskellers, in
> particular on avoiding the IO monad, is motivated by the quest for elegance.
> 

By some experienced Haskellers. Others pile them on where they feel it's
appropriate, though avoiding IO where possible is still a good
principle.

I often find that less is essentially stateful than it looks. However, I
also find that as I decompose tasks - especially if I'm willing to
'de-fuse' things - then state-like dataflows crop up again in places
where they had been eliminated. Especially if I want to eg instrument or
quietly abstract some code. Spotting particular sub-cases like Reader
and Writer is a gain, of course!

> A good example is probably the HGL (Haskell Graphics Library), a small
> vector graphics library which once shipped with Hugs. The core is the type
> 
>   Graphic
> 
> which represents a drawing and whose semantics are roughly
> 
>   Graphic = Pixel -> Color



> After having constructed a graphic, you'll also want to draw it on
> screen, which can be done with the function
> 
>   drawInWindow :: Graphic -> Window -> IO ()
> 

Note that there are two different things going on here. The principle of
building up 'programs' in pure code to execute via IO is good - though
ironically enough, plenty of combinator libraries for such tasks form
monads themselves. Finding the right domain for DSL programs is also
important, but this is not necessarily as neatly functional. If you
start with a deep embedding rather than a shallow one then this isn't
much of a problem even if you find your first attempt was fatally flawed
- the DSL code's just another piece of data. 

-- 
Philippa Cowderoy 

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

[Haskell-cafe] Gtk2Hs on Windows for GHC 6.10.1

[Peter Verswyvelen]

Gtk2Hs 0.9.13 has an annoying bug on Windows that makes it impossible to run
via GHCi.
So to see if the latest development version works better, I tried to build
it on Windows using GHC 6.10.1, but I failed to do so with both MSYS and
Cygwin.

Does anybody know how to build it on Windows?

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Derek Elkins]

On Mon, 2009-01-12 at 20:23 +0100, Bas van Dijk wrote:
> On Mon, Jan 12, 2009 at 6:06 PM, Robin Green  wrote:
> > The fix-style equivalent to your repeat above, would be something like
> > this:
> >
> > repeat x = fix $ \me -> x ::: me
> 
> Interesting.

The definition of fix is small and non-recursive, in particular it is:
fix f = let x = f x in x
When inlined, which it -will- be if optimizations are enabled, 
fix (x:::) is -identical- to your definition of repeat.

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

[Haskell-cafe] Re: System.CPUTime and picoseconds

[ChrisK]

Tony Finch wrote:

The FreeBSD kernel uses a 64+64 bit fixed point type to represent time,
where the integer part is a normal Unix time_t. The fractional part is
64 bits wide in order to be able to represent multi-GHz frequencies
precisely.


"multi-GHz" being a euphemism for 18.45*10^9 GHz, over 18 billion GHz.

I just read through that. The granularity is 2^-64 seconds, or 5.4*^-20 seconds? 
That is 54 nano-pico-seconds.  I can see needing better than nanosecond, and 
going to milli-nanoseconds like Haskell, but to jump close to pico-nano-seconds? 
 That skips right past micro-nano-seconds and nano-nano-seconds.  That's 20 
million times more resolution than Haskell's picoseconds.  My that was fun to write.


It looks like an excellent performance hack for OS kernels.  64-bits make for 
simple register and cache access, the compiled code is small and quick, etc.


As a portable API it is far too complicated to use.  Not in the least because 
only FreeBSD probably has that API.


Note that at 10^-20 seconds the general relativistic shift due to altitude will 
matter over less than the thickness of a closed laptop.  Defining "now" that 
accurately has meaning localized to less then your computer's size.  The 
warranty for the bottom of your screen will expire sooner than that of the top.


Only stock traders and relativistic particles care about time intervals that 
short. "FreeBSD — designed for the interstellar craft to tomorrow"


Hmm...The W and Z bosons decay the fastest with 10^-25 second lifetimes, the 
shortest known lifetimes that I can find.  The fundamental Planck scale, the 
shortest amount of time in today's physics, is 5.4*10^-44 seconds.  So with 80 
more bits FreeBSD would be at the fundamental limit.  Of course the conversion 
then depends on the values of h, c, and G.


Now that would also be a good April Fool's joke proposal.

--
Chris

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Derek Elkins]

On Mon, 2009-01-12 at 19:43 +0100, Bas van Dijk wrote:
> On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke
>  wrote:
> > GHC should indeed be doing so. I'm working (on and off) to work out
> > some suitable heuristics and put the transformation into ghc -O2.
> > There are a few wrinkles that still need sorting out, but preliminary
> > indications are that it decreases the runtime of our standard
> > benchmark suite, nofib, by 12% or so.
> 
> Great!
> 
> In the Stream library I'm developing at http://code.haskell.org/Stream
> I 'closurize' (for lack of a better name) 

One name for this transformation (or one very closely related to it) is
lambda-dropping which was chosen to contrast to the better known
transformation, lambda lifting.

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

Re: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1

[Andrew Hunter]

On Mon, Jan 12, 2009 at 10:11:19PM +, ChrisK wrote:
> Haskeline is designed to remove the readline dependency, because Windows 
> does not have readline.  So rlwrap is useless there.
>

Ah, I hadn't considered Windows support--that makes sense.  Thanks,
that answers my questions.

AHH

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

[Haskell-cafe] A pattern type signature cannot bind scoped type variables `t'

[rodrigo.bonifacio]

Hi all,
I'm trying to build a library that has the following code:
hasTypeOf (TermRep (dx,_,_)) (x::t) = ((fromDynamic dx)::Maybe t)
 
When I try to compile with ghc-6.8.3 I got the following error:
../../StrategyLib/models/drift-default//TermRep.hs:63:30: A pattern type signature cannot bind scoped type variables `t' unless the pattern has a rigid type context In the pattern: x :: t In the definition of `hasTypeOf': hasTypeOf (TermRep (dx, _, _)) (x :: t) = ((fromDynamic dx) :: Maybe t)
 
How can I solve this problem? Is there any option to ignore this erro when compiling with ghc-6.8.3?
Thanks for any help.
Rodrigo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1

[Roman Cheplyaka]

* Andrew Hunter  [2009-01-12 13:41:03-0800]
> On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote:
> > I'm pleased to announce the first release of ghci-haskeline.  This
> > package uses the GHC API to reimplement ghci with the Haskeline
> > library as a backend.  Haskeline is a library for line input in
> > command-line programs, similar to readline or editline, which is
> > written in Haskell and thus (hopefully) more easily integrated into
> > other Haskell programs.
> > 
> 
> Perhaps this has already been discussed at length, in which case I
> apologize but, well, why provide line input editing at all?
> 
> A number of languages/programs (off the top of my head: sml, most
> Schemes) don't; the standard method to get line editing is rlwrap.
> And this works (in my limited experience) quite well.  The
> disadvantage as I see it of using editline or Haskeline or whatever is
> that it's going to be sutbly different than other methods; presumably,
> people won't like the changes in behavior.
> 
> It seems to me that from a UNIX-y separation of concern view, the
> right thing to do (as many languages have chosen) is to /not/ provide
> line editing, and just let the user do that with any number of
> convenient tools that focus on getting/that/ right (like rlwrap.)  Is
> there a reason we've not taken that approach?

For example, ghci does more intelligent completion than rlwrap probably
can do:
X -> no matches
:m X -> XMonad

-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1

[ChrisK]

Haskeline is designed to remove the readline dependency, because Windows does 
not have readline.  So rlwrap is useless there.



Andrew Hunter wrote:

On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote:

I'm pleased to announce the first release of ghci-haskeline.  This
package uses the GHC API to reimplement ghci with the Haskeline
library as a backend.  Haskeline is a library for line input in
command-line programs, similar to readline or editline, which is
written in Haskell and thus (hopefully) more easily integrated into
other Haskell programs.



Perhaps this has already been discussed at length, in which case I
apologize but, well, why provide line input editing at all?

A number of languages/programs (off the top of my head: sml, most
Schemes) don't; the standard method to get line editing is rlwrap.
And this works (in my limited experience) quite well.  The
disadvantage as I see it of using editline or Haskeline or whatever is
that it's going to be sutbly different than other methods; presumably,
people won't like the changes in behavior.

It seems to me that from a UNIX-y separation of concern view, the
right thing to do (as many languages have chosen) is to /not/ provide
line editing, and just let the user do that with any number of
convenient tools that focus on getting/that/ right (like rlwrap.)  Is
there a reason we've not taken that approach?

Thanks,
AHH


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

[Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1

[Andrew Hunter]

On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote:
> I'm pleased to announce the first release of ghci-haskeline.  This
> package uses the GHC API to reimplement ghci with the Haskeline
> library as a backend.  Haskeline is a library for line input in
> command-line programs, similar to readline or editline, which is
> written in Haskell and thus (hopefully) more easily integrated into
> other Haskell programs.
> 

Perhaps this has already been discussed at length, in which case I
apologize but, well, why provide line input editing at all?

A number of languages/programs (off the top of my head: sml, most
Schemes) don't; the standard method to get line editing is rlwrap.
And this works (in my limited experience) quite well.  The
disadvantage as I see it of using editline or Haskeline or whatever is
that it's going to be sutbly different than other methods; presumably,
people won't like the changes in behavior.

It seems to me that from a UNIX-y separation of concern view, the
right thing to do (as many languages have chosen) is to /not/ provide
line editing, and just let the user do that with any number of
convenient tools that focus on getting/that/ right (like rlwrap.)  Is
there a reason we've not taken that approach?

Thanks,
AHH

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

Re: [Haskell-cafe] Data analysis with Haskell

[Don Stewart]

d:
> Hi all,
> 
> I'm going to start a project where I'll have to do some data analysis 
> (statistics about product orders) based on database entries; it will 
> mostly be some very basic stuff like grouping by certain rules and 
> finding averages as well as summing up and such.  It will however be 
> more than what can be done directly in the database using SQL, so there 
> will be some processing in my program.
> 
> I'm thinking about trying to do this in Haskell (because I like this 
> language a lot); however, it is surely not my most proficient language 
> and I tried to do some number crunching (real one that time) before in 
> Haskell where I had to deal with some 4 million integer lists, and this 
> failed; the program took a lot more memory than would have been 
> necessary and ran for several minutes (kept swapping all the time, too). 
>  A rewrite in Fortran did give the result in 6s and didn't run out of 
> space.

**Don't use lists when you mean to use arrays**

E.g. multiple two 4M element arrays, map over the result and sum that.

import Data.Array.Vector

main = print . sumU . mapU (+7) $ zipWithU (*)
(enumFromToU 1 (400 :: Int))
(enumFromToU 2 (401 :: Int))

Compile it:

$ ghc -O2 -fvia-C -optc-O3 -funbox-strict-fields --make

$ time ./A
2886605259654448384
./A  0.03s user 0.00s system 97% cpu 0.034 total

Not the end of the world at all.
  
> This was probably my fault at that time, because I surely did something 
> completely wrong for the Haskell style.  However, I fear I could run 
> into problems like that in the new project, too.  So I want to ask for 
> your opinions, do you think Haskell is the right language to do data 

You want to compile Haskell DB queries into SQL?

> analysis of this kind?  And do you think it is hard for still beginner 
> Haskell programmer to get this right so Haskell does not use up a lot of 
> memory for thunks or list-overhead or things like that?  And finally, 
> are there database bindings for Haskell I could use for the queries?

There are lots of database bindings. Very popular ones are HDBC and
Takusen. Check on hackage.haskell.org

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

[Haskell-cafe] Data analysis with Haskell

[Daniel Kraft]

Hi all,

I'm going to start a project where I'll have to do some data analysis 
(statistics about product orders) based on database entries; it will 
mostly be some very basic stuff like grouping by certain rules and 
finding averages as well as summing up and such.  It will however be 
more than what can be done directly in the database using SQL, so there 
will be some processing in my program.


I'm thinking about trying to do this in Haskell (because I like this 
language a lot); however, it is surely not my most proficient language 
and I tried to do some number crunching (real one that time) before in 
Haskell where I had to deal with some 4 million integer lists, and this 
failed; the program took a lot more memory than would have been 
necessary and ran for several minutes (kept swapping all the time, too). 
 A rewrite in Fortran did give the result in 6s and didn't run out of 
space.


This was probably my fault at that time, because I surely did something 
completely wrong for the Haskell style.  However, I fear I could run 
into problems like that in the new project, too.  So I want to ask for 
your opinions, do you think Haskell is the right language to do data 
analysis of this kind?  And do you think it is hard for still beginner 
Haskell programmer to get this right so Haskell does not use up a lot of 
memory for thunks or list-overhead or things like that?  And finally, 
are there database bindings for Haskell I could use for the queries?


Thanks a lot!

Daniel

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

Re: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses

[Ryan Ingram]

Here's a minimal bit of code that gives you the error:

> data FL p x z where
> ConsFL :: p x y -> FL p y z -> FL p x z
> NilFL :: FL p x x
> data GTE a1 a2 x z where
> GTE :: a1 x y -> a2 y z -> GTE a1 a2 x z

> ccwo (ConsFL x xs) (ConsFL y ys) =
>case ccwo xs ys of
>GTE nx ny -> undefined

However, your problem goes further than this; if we add the NilFL
cases, you *need* to understand the type of ccwo and qualify it with a
type signature, or else you get the "GADT pattern match in non-rigid
context" error.  The reason it doesn't show up in this first case is
that ConsFL isn't using all the powers of GADTs; it can be represented
with just existential types.

So, FL p represents an element of the transitive closure of p over
types; that is, if you have

ab :: P A B
ac :: P A C
bd :: P B D
cd :: P C D

then you can get the following FLs:

NilFL :: FL P x x -- for any x
ConsFL ab NilFL :: FL P A B
ConsFL ac NilFL :: FL P A C
ConsFL bd NilFL :: FL P B D
ConsFL cd NilFL :: FL P C D
abd = ConsFL ab (ConsFL bd NilFL) :: FL P A D
acd = ConsFL ac (ConsFL cd NilFL) :: FL P A D

Note the two separate constructions of FL P A D.  This means your
suggested type for ccwo can't work; consider "ccwo abd acd".  The
existentially held type in the first list is "B", and in the second
list is "C".

So, what do you expect compare_changes_with_old to do in this
"diamond" case?  I think if you understand that, you'll be able to
figure out a working definition.

  -- ryan

On Mon, Jan 12, 2009 at 10:21 AM, Rob Hoelz  wrote:
> I should've included these when I forwarded it, but that was pre-coffee
> today. =P
>
> class MyEq p where
>  unsafeCompare :: p C(a b) -> p C(c d) -> Bool
>  -- more stuff
>
> data FL a C(x z) where
>  (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z)
>  NilFL :: FL a C(x x)
>
> data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y))
> infixr 1 :>
>
> -- I'm not entirely sure on this one, because type witnesses confuse me.
> compare_changes_with_old :: (Patchy p) =>
>  FL p C(x y)
>   -> FL p C(x y)
>   -> (FL p :> FL p) C(x y)
>
> C(args...) is a preprocessor macro that expands to args if Darcs is
> building with GADT type witnesses.  FORALL(args...) expands to forall
> args. under the same condition.
>
> All of the definitions are available at
> http://darcs.net/api-doc/doc-index.html as well.
>
> Thanks,
> Rob
>
> "Ryan Ingram"  wrote:
>
>> Some questions first:
>> What's the type of this function supposed to be?
>> What's the type of unsafeCompare?
>> How is the data type with NilFL and :>: defined?
>>
>>   -- ryan
>>
>> On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz  wrote:
>> > Forwarding to Haskell Cafe per Eric's suggestion.
>> >
>> > Begin forwarded message:
>> >
>> > Date: Sun, 11 Jan 2009 23:01:31 -0600
>> > From: Rob Hoelz 
>> > To: darcs-de...@darcs.net
>> > Subject: [darcs-devel] "Inferred type is less polymorphic than
>> > expected" and type witnesses
>> >
>> >
>> > Hello again, Darcs users and developers,
>> >
>> > As I mentioned in my last e-mail, I'm working on
>> > http://bugs.darcs.net/issue291.  It's actually gone pretty well,
>> > and I feel I'm just about finished (I've done all but sorting out
>> > the changes after leaving the editor), only I've encountered the
>> > compiler error you see in the subject of this message. This error
>> > only appears when compiling with witnesses. Here's the source for
>> > the function that it's complaining about:
>> >
>> > compare_changes_with_old (x :>: xs) (y :>: ys) =
>> >  case compare_changes_with_old xs ys of
>> >nx :> ny -> if unsafeCompare x y
>> >  then ((x :>: nx) :> ny)
>> >  else (NilFL :> (y :>: ys))
>> > compare_changes_with_old NilFL NilFL = (NilFL :> NilFL)
>> > compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys)
>> > compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL)
>> >
>> > Now, I have two questions:
>> >
>> > 1) What exactly does this error mean, and how do I get around it?
>> > 2) What are witness types, and what are they used for?
>> >
>> > I will gladly accept links to fine manuals as answers to either
>> > question, but simple explanations would be nice. =D  I thought I
>> > understood Haskell pretty well, but existentially qualified types
>> > have thrown me for a loop.
>> >
>> > Thanks much,
>> > Rob Hoelz
>> > ___
>> > darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!)
>> > darcs-de...@darcs.net
>> > http://lists.osuosl.org/mailman/listinfo/darcs-devel
>> > ___
>> > 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] Multiple State Monads

[minh thu]

2009/1/12 Phil :
> Hi,
>
> I've been reading the Monads aren't evil posts with interest – I'm a 2nd
> week Haskell newbie and I'm doing my best to use them where (I hope) it is
> appropriate.  Typically I'm writing my code out without using Monads
> (normally using list recursion), and then when I get them working, I delve
> into the Monad world This has been going well so far with a bit of help
> from you guys, but I've hit a snag.
>
> In the code below I'm using a state Monad (getEvolution), but unlike simpler
> cases I'm passing around two items of state, and one of these states is also
> ultimately a result – although I don't care about the result until I reach
> an end state.  My implementation is a bit ugly to say the least and clearly
> I'm forcing round pegs into square holes here – reading a bit online I get
> the impression that I can solve the two-state issue using Monad
> Transformers, by  wrapping a StateT around a regular State object (or even
> two StateT Monads around an Identity Monad??).  I think I understand the
> theory here, but any attempt to implement it leads to a horrible mess that
> typically doesn't compile.  The other problem of having a state that is also
> a result, I'm sure what to do about this.
>
> Was wondering if anyone could give me a push in the right direction – how
> can I rework my state monad so that it looks less wildly.
>
> Many thanks,
>
> Phil.
>
> mcSimulate :: Double -> Double -> Word64 -> [Double]
> mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate
> startStock endTime newSeedForSeed
>   where
> expiryStock =  evalState ( do replicateM_ (truncate(endTime/timeStep)-1)
> getEvolution; getEvolution )
>$ (startStock,ranq1Init seedForSeed)
> newSeedForSeed = seedForSeed + 246524
>
> discount :: Double -> Double -> Double -> Double
> discount stock r t = stock * exp (-r)*t
>
> payOff :: Double -> Double -> Double
> payOff strike stock | (stock - strike) > 0 = stock - strike
> | otherwise = 0
>
> -- Monad Implementation
>
> -- Yuk!
> evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) )
> evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) )
>   where
> newState = ranq1Increment state
> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
> vol*sqrt(timeStep)*normalFromRngState(state) ) )
>
> getEvolution :: State (Double, Word64) Double
> getEvolution = State evolveUnderlying

Hi,

the evolveUnderlying can simply manipulate the state, so you can

do evolveUnderlying -- state (not your state, but the tuple) changes here
   r <- gets fst -- query the state for the first element of the tuple
   return r -- simply return what you want

Note that if you want to combine your state and the stock, you simply end
with a new kind of state : the tuple (thus, no need to compose two State)

Note also, since evolveUnderlying only manipulates the internal state of the
State monad, it returns ().

Depending on how you want to structure your code, you can also use execState
instead of evalState : it returns the state on which you can use fst.

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

[Haskell-cafe] haskell-platform mailing list

[Duncan Coutts]

Hi all,

If you are interested in helping out with the haskell platform project
then we invite you to subscribe to the haskell-platform mailing list.

http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform

This mailing list is for discussing practical stuff. We expect to
discuss policy questions on the libraries mailing list.

Issues like which packages to pick, what package QA standards to use etc
would be discussed on the libraries mailing list. Those issues are for
the community as a whole. Building and coordinating the actual releases
will be done via the haskell-platform mailing list.

Duncan

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

Re: [Haskell-cafe] Re: Monads aren't evil? I think they are.

[Henning Thielemann]

Ertugrul Soeylemez schrieb:
> "Apfelmus, Heinrich"  wrote:
> 
>> The insistence on avoiding monads by experienced Haskellers, in
>> particular on avoiding the IO monad, is motivated by the quest for
>> elegance.
>>
>> The IO and other monads make it easy to fall back to imperative
>> programming patterns to "get the job done".  [...]
> 
> Often, the monadic solution _is_ the elegant solution.  Please don't
> confuse monads with impure operations.  I use the monadic properties of
> lists, often together with monad transformers, to find elegant
> solutions.  As long as you're not abusing monads to program
> imperatively, I think, they are an excellent and elegant structure.

I have seen several libraries where all functions of a monad have the
monadic result (), e.g. Binary.Put and other writing functions. This is
a clear indicator, that the Monad instance is artificial and was only
chosen because of the 'do' notation.

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

[Haskell-cafe] Multiple State Monads

[Phil]

Hi,

I¹ve been reading the Monads aren¹t evil posts with interest ­ I¹m a 2nd
week Haskell newbie and I¹m doing my best to use them where (I hope) it is
appropriate.  Typically I¹m writing my code out without using Monads
(normally using list recursion), and then when I get them working, I delve
into the Monad world This has been going well so far with a bit of help
from you guys, but I¹ve hit a snag.

In the code below I¹m using a state Monad (getEvolution), but unlike simpler
cases I¹m passing around two items of state, and one of these states is also
ultimately a result ­ although I don¹t care about the result until I reach
an end state.  My implementation is a bit ugly to say the least and clearly
I¹m forcing round pegs into square holes here ­ reading a bit online I get
the impression that I can solve the two-state issue using Monad
Transformers, by  wrapping a StateT around a regular State object (or even
two StateT Monads around an Identity Monad??).  I think I understand the
theory here, but any attempt to implement it leads to a horrible mess that
typically doesn¹t compile.  The other problem of having a state that is also
a result, I¹m sure what to do about this.

Was wondering if anyone could give me a push in the right direction ­ how
can I rework my state monad so that it looks less wildly.

Many thanks,

Phil.

mcSimulate :: Double -> Double -> Word64 -> [Double]
mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate
startStock endTime newSeedForSeed
  where
expiryStock =  evalState ( do replicateM_ (truncate(endTime/timeStep)-1)
getEvolution; getEvolution )
   $ (startStock,ranq1Init seedForSeed)
newSeedForSeed = seedForSeed + 246524

discount :: Double -> Double -> Double -> Double
discount stock r t = stock * exp (-r)*t

payOff :: Double -> Double -> Double
payOff strike stock | (stock - strike) > 0 = stock - strike
| otherwise = 0

-- Monad Implementation

-- Yuk! 
evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) )
evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) )
  where
newState = ranq1Increment state
newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + (
vol*sqrt(timeStep)*normalFromRngState(state) ) )

getEvolution :: State (Double, Word64) Double
getEvolution = State evolveUnderlying



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

Re: [Haskell-cafe] Monads aren't evil? I think they are.

[Henning Thielemann]

Apfelmus, Heinrich schrieb:
> Ertugrul Soeylemez wrote:
>> Let me tell you that usually 90% of my code is
>> monadic and there is really nothing wrong with that.  I use especially
>> State monads and StateT transformers very often, because they are
>> convenient and are just a clean combinator frontend to what you would do
>> manually without them:  passing state.
> 
> The insistence on avoiding monads by experienced Haskellers, in
> particular on avoiding the IO monad, is motivated by the quest for elegance.
> 
> The IO and other monads make it easy to fall back to imperative
> programming patterns to "get the job done". But do you really need to
> pass state around? Or is there a more elegant solution, an abstraction
> that makes everything fall into place automatically? Passing state is a
> valid implementation tool, but it's not a design principle.

I collected some hints, on how to avoid at least the IO monad:
  http://www.haskell.org/haskellwiki/Avoiding_IO

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

Re: [Haskell-cafe] unfoldr [ANN: HLint 1.2]

[Henning Thielemann]

On Mon, 12 Jan 2009, Andrew Coppin wrote:


Off the top of my head, try this:

convert b 0 = []
convert b n = n `mod` b : convert b (n `div` b)

(Takes a number and yields the radix-B representation of it. Backwards.)

convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) else 
Nothing)


I have the nice function 'toMaybe' which simplifies this to:
  unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b))

Maybe HLint can also suggest non-base functions? ;-)

http://hackage.haskell.org/packages/archive/utility-ht/0.0.2/doc/html/Data-Maybe-HT.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] HaskellWiki Upgrade Aborted

[Henning Thielemann]

On Sun, 11 Jan 2009, Duncan Coutts wrote:


We really need to upgrade the whole thing. Not an easy job given the
range of stuff being run on there by lots of different people.


Btw. is there a simple way to download all the Wiki content?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] unfoldr [ANN: HLint 1.2]

[Andrew Coppin]

Neil Mitchell wrote:

Hi Andrew,

  

HLint will automatically detect if you should have used a map, a foldr
or a foldl and suggest how to change your code. In the GHC, darcs and
Hoogle code bases there are no obvious map-like functions, which is a
good sign :-)

  

...What an intriguing idea. Clearly I'm going to have to play with this
sometime soon.

Does it suggest unfoldr too?



No, but it could do in the future - I never use unfold's in my code,
so am not really familiar with them. But I will look into them, do you
have any examples where it should suggest unfoldr so I can play with
them?
  


Off the top of my head, try this:

 convert b 0 = []
 convert b n = n `mod` b : convert b (n `div` b)

(Takes a number and yields the radix-B representation of it. Backwards.)

 convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) 
else Nothing)


It's also useful for converting a data structure into a list:

 heap_to_list = unfoldr (\h -> if heap_empty h then Nothing else Just 
(heap_top h, heap_delete_top h))


Those are the major uses I'm aware of. I'm sure somebody else will think 
of others. (IIRC, unstream is implemented as an unfold...?)


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

Re: [Haskell-cafe] Generalized partial application (again)

[Peter Verswyvelen]

On Mon, Jan 12, 2009 at 8:33 PM, Felipe Lessa wrote:

>
> z1' = let f = (let y1 = e1 1; y2 = e2 2 in (\x -> op2 y2 y1 x)) in (f 3, f
> 4)


oooh! sweet! I didn't think of that. many thanks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Generalized partial application (again)

[Felipe Lessa]

How about using "let"s?

2009/1/12 Peter Verswyvelen :
> e = trace "e"
> op = (+)
> a1 = let f = (op (e 1)) in (f 10, f 100)
> a2 = let f = (\x -> op (e 1) x) in (f 10, f 100)
> a1 and a2 are operationally not the same: a1 will evaluate (e 1) once, a2

a3 = let f = (let y = e 1 in (\x -> op y x)) in (f 10, f 100)

> e1 x = trace "e1" x
> e2 x = trace "e2" x
> op2 :: Int -> Int -> Int -> Int
> op2 x y z = x+10*y+100*z
> z1 = let f = (flip3_12 op2) (e1 1) (e2 2) in (f 3, f 4)
> z2 = let f = (flip3_13 op2) (e1 1) (e2 2) in (f 3, f 4)
> z3 = let f = (flip3_23 op2) (e1 1) (e2 2) in (f 3, f 4)

z1' = let f = (let y1 = e1 1; y2 = e2 2 in (\x -> op2 y2 y1 x)) in (f 3, f 4)

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

Re: [Haskell-cafe] ANN: bytestring-trie 0.1.4

[Don Stewart]

Do you have any benchmarks comparing dictionaries against Map ByteString
Int, or Map String Int?

-- Don

wren:
> 
> -- bytestring-trie 0.1.4
> 
> 
> Another release for efficient finite maps from (byte)strings to values. 
> Equal parts bugfix release and real release. This upgrade is suggested 
> for all users and is what 0.1.0 should have been.
> 
> 
> 
> -- Changes (since 0.1.2)
> 
> 
> * Fixed a number of obscure bugs when "" is used as a key.
> 
> * Added keys and toListBy (which generalizes toList, keys,...). Also did 
> some optimization of toListBy so it shouldn't be as egregiously 
> inefficient as it was before.
> 
> * Added fromListL, fromListR, and fromListS to Data.Trie.Convenience 
> along with notes about when each is more efficient than the others.
> 
> * Separated Data.Trie (the main module for users) from 
> Data.Trie.Internal (gritty details, and core implementation). Data.Trie 
> re-exports most of Data.Trie.Internal so this is primarily a cosmetic 
> change. The showTrie and lookupBy_ functions are no longer exported from 
> Data.Trie however.
> 
> 
> 
> -- Links
> 
> 
> Homepage:
> http://code.haskell.org/~wren/
> 
> Hackage:
> 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie
> 
> Darcs:
> http://code.haskell.org/~wren/bytestring-trie/
> 
> Haddock (Darcs version):
> 
> http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/
> 
> -- 
> Live well,
> ~wren
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Generalized partial application (again)

[Peter Verswyvelen]

Please correct me if I'm wrong in any of the reasoning below.

Haskell provides the ability the perform partial application on the
rightmost arguments.
I learned from some pretty smart guys that partial application cannot be
emulated with lambas, because they behave differently operationally, e.g.

e = trace "e"
op = (+)

a1 = let f = (op (e 1)) in (f 10, f 100)
a2 = let f = (\x -> op (e 1) x) in (f 10, f 100)

a1 and a2 are operationally not the same: a1 will evaluate (e 1) once, a2
will evaluate it twice.

However, Haskell also allows to partially apply the second argument of
binary functions (using sections)

b1 = let f = (`op` (e 1)) in (f 10, f 100)
b2 = let f = (\x -> (e 1) `op` x) in (f 10, f 100)

Again, b1 evaluates (e 1) once, b2 twice.

b1 is actually the same as

c1 = let f = ((flip op) (e 1)) in (f 10, f 100)

So for ternary functions we could write more permutations of flip:

flip3_12 f a1 a2 a3 = f a2 a1 a3
flip3_13 f a1 a2 a3 = f a3 a2 a1
flip3_23 f a1 a2 a3 = f a1 a3 a2

And use these to partially apply any argument

e1 x = trace "e1" x
e2 x = trace "e2" x

op2 :: Int -> Int -> Int -> Int
op2 x y z = x+10*y+100*z

z1 = let f = (flip3_12 op2) (e1 1) (e2 2) in (f 3, f 4)
z2 = let f = (flip3_13 op2) (e1 1) (e2 2) in (f 3, f 4)
z3 = let f = (flip3_23 op2) (e1 1) (e2 2) in (f 3, f 4)

This could be extended to N-ary functions. Haskell doesn't give any special
syntactic support for this, but it surely is possible.

Am I missing something here? Is there any easier way to perform "generalized
partial application"?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: HLint 1.2

[Bas van Dijk]

On Mon, Jan 12, 2009 at 6:06 PM, Robin Green  wrote:
> The fix-style equivalent to your repeat above, would be something like
> this:
>
> repeat x = fix $ \me -> x ::: me

Interesting.

Your repeat and mine are compiled to the same code:

Data.Stream.repeat :: forall a_aVi.
  a_aVi -> Data.Stream.Stream a_aVi

Data.Stream.repeat =
  \ (@ a_a2lT) (x_aZ6 :: a_a2lT) ->
letrec {
  repeat_x_s50K :: Data.Stream.Stream a_a2lT

  repeat_x_s50K = Data.Stream.::: @ a_a2lT x_aZ6 repeat_x_s50K; } in
repeat_x_s50K

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Henning Thielemann]

On Mon, 12 Jan 2009, Robin Green wrote:


I tend to use Control.Monad.Fix.fix (which actually has nothing to do
with monads, despite the package name)


That's why it is also available from Data.Function now:
   http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Function.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Question about touchForeignPtr

[Patrick Perry]

Thanks for your help, Duncan.

On Jan 12, 2009, at 6:10 AM, Duncan Coutts wrote:


Do the (ForeignPtr e) and the (Ptr e) point to the same thing? They

appear to be related because you dereference p but touch f.

It used to be the ForeignPtr was slower to dereference than a Ptr  
and so

caching it like this could make it faster (but then requires lots of
careful thought about touchForeignPtr). These days ForeignPtr is  
just as

fast and so you can use withForeignPtr and never have to worry about
touchForeignPtr. You'll notice ByteString works this way.


Often they point to the same thing, but not always.  If they pointed to
the same thing, I wouldn't store p separately, but often p has a nonzero
offset from f.  You either have to store the offset or cache the  
pointer.

I found that it was both faster and simpler to cache p rather than the
offset.


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

Re: [Haskell-cafe] ANN: HLint 1.2

[Robin Green]

On Mon, 12 Jan 2009 19:43:00 +0100
"Bas van Dijk"  wrote:

> On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke
>  wrote:
> > GHC should indeed be doing so. I'm working (on and off) to work out
> > some suitable heuristics and put the transformation into ghc -O2.
> > There are a few wrinkles that still need sorting out, but
> > preliminary indications are that it decreases the runtime of our
> > standard benchmark suite, nofib, by 12% or so.
> 
> Great!
> 
> In the Stream library I'm developing at http://code.haskell.org/Stream
> I 'closurize' (for lack of a better name) all my functions. Here are a
> few random examples:
> 
> repeat :: a -> Stream a
> repeat x = repeat_x
> where
>   repeat_x = x ::: repeat_x
> 
> cycle :: [a] -> Stream a
> cycle xs = cycle_xs
> where
>   cycle_xs = foldr (:::) cycle_xs xs
> 
> deleteBy :: (a -> a -> Bool) -> a -> Stream a -> Stream a
> deleteBy eq x = deleteBy_eq_x
> where
>   deleteBy_eq_x (y ::: ys)
>   | eq x y= ys
>   | otherwise = y ::: deleteBy_eq_x ys
> 
> Closurizing the functions in Data.Stream lead to 10% to 250% speedups!

Awesome!

I tend to use Control.Monad.Fix.fix (which actually has nothing to do
with monads, despite the package name) sometimes, for "closurizing" a
recursive function. I am curious as to whether the "fix" style of
recursive programming is likely to result in the same speedups.

The fix-style equivalent to your repeat above, would be something like
this:

repeat x = fix $ \me -> x ::: me

(I use "me" for the name of the recursive call, partly because it
reminds me that it's a self-call, and partly because I find it amusing)

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

Re: [Haskell-cafe] data, util, and lang packages

[Don Stewart]

rodrigo.bonifacio:
>Hi all, I'm trying to build a library whose configuration process requires
>the data, util, and lang packages. I guess that these are *deprecated*
>packages, since the library is said to be ghc 6.4.1 compliant.
> 
>Which packages should I use instead?
> 
>Where can I find such packages (if they are not deprecated)
> 
>Thanks in advance.

Those don't exist. They were merged into the haskell98 package several
years ago.



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

Re: [Haskell-cafe] ANN: HLint 1.2

[Jan-Willem Maessen]

On Jan 12, 2009, at 12:47 PM, Max Bolingbroke wrote:


2009/1/12 Jan-Willem Maessen :

On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote:

No because the current definition are recursive and ghc cannot  
inline

recursive functions.



Then the map can be inlined at the call site and the 'f' inlined  
into

the body of 'go'.


This seems like exactly the sort of mechanical transformation that  
computers
do quickly and accurately, and humans get wrong.  Surely it  
wouldn't be that
hard for GHC to transform self recursion in this way (possibly  
subject to

the condition that the result be worth inlining)?


GHC should indeed be doing so. I'm working (on and off) to work out
some suitable heuristics and put the transformation into ghc -O2.
There are a few wrinkles that still need sorting out, but preliminary
indications are that it decreases the runtime of our standard
benchmark suite, nofib, by 12% or so.


This is excellent news, quite apart from Don's observation that it  
isn't particularly relevant for map (where we are essentially using  
RULES to instantiate an alternative definition in terms of foldr/ 
build, if I understand his message rightly).  Self recursion is abut  
so much more than map!


-Jan


Cheers,
Max


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

[Haskell-cafe] data, util, and lang packages

[rodrigo.bonifacio]

Hi all, I'm trying to build a library whose configuration process requires the data, util, and lang packages. I guess that these are *deprecated* packages, since the library is said to be ghc 6.4.1 compliant.
Which packages should I use instead?
Where can I find such packages (if they are not deprecated)
Thanks in advance.
Rodrigo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: HLint 1.2

[Bas van Dijk]

On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke
 wrote:
> GHC should indeed be doing so. I'm working (on and off) to work out
> some suitable heuristics and put the transformation into ghc -O2.
> There are a few wrinkles that still need sorting out, but preliminary
> indications are that it decreases the runtime of our standard
> benchmark suite, nofib, by 12% or so.

Great!

In the Stream library I'm developing at http://code.haskell.org/Stream
I 'closurize' (for lack of a better name) all my functions. Here are a
few random examples:

repeat :: a -> Stream a
repeat x = repeat_x
where
  repeat_x = x ::: repeat_x

cycle :: [a] -> Stream a
cycle xs = cycle_xs
where
  cycle_xs = foldr (:::) cycle_xs xs

deleteBy :: (a -> a -> Bool) -> a -> Stream a -> Stream a
deleteBy eq x = deleteBy_eq_x
where
  deleteBy_eq_x (y ::: ys)
  | eq x y= ys
  | otherwise = y ::: deleteBy_eq_x ys

Closurizing the functions in Data.Stream lead to 10% to 250% speedups!

Note that I follow a particular naming convention for the inner worker
functions. I use the top level function name and append the
'closurized' arguments to it interspersed with underscores.

regards,

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Don Stewart]

dons:
> ndmitchell:
> > Hi
> > 
> > > Does GHC specialize map?  If it doesn't, then hand crafted version
> > > could be faster.
> > 
> > GHC doesn't specialize map, and a hand-crafted one could be faster -
> > but you then wouldn't get foldr/build fusion. In general HLint tries
> > to make the code prettier, but sometimes you will need to deviate from
> > its suggestions when you've profiled etc. To stop HLint warning you
> > just create Hints.hs and include the line "ignore =
> > LennartsSuperFastModule.mySpecialisedMap" - full details in the
> > manual.
> > 
> > >> I found so many 'map' re-implementations in Haskell libraries, even in
> > >> those, where I thought their programmers must be more experienced than 
> > >> me.
> > >> Hm, maybe even in libraries by Neil?
> > 
> > I can't really be blamed for making mistakes before HLint ;-)
> > 
> 
> But GHC tends to inline and specialise map, due to:
> 
> "map"   [~1] forall f xs.   
> map f xs = build (\c n -> foldr (mapFB c f) n xs)
> 
> So that,
> 
> main = print (map toUpper "haskell")
> 
> Yields:
> 
>   s :: Addr#
>   s = "haskell"#
> 
>   letrec
> unpack_snX :: Int# -> [Char]
> unpack_snX = \ (x :: Int#) ->
> case indexCharOffAddr# s x of i { 
>   _  -> ($wtoUpper i) (: @ Char) (unpack_snX (+# x 1)
>   '\NUL' -> [] @ Char
> 
> Which looks inlined and specialised to my eyes.
> 

Oh, I should note the inlining only happens here since the list constant
is a 'build', and map is a bulid . foldr, so we get a build/foldr
fusion, and an inlined map as a result.

If we just use map in isolation, no inlining:

A.foo =
  \ (xs_ala :: [Char]) ->
  map @ Char @ Char toUpper xs_ala

Whereas a worker/wrapper version

map :: (a -> b) -> [a] -> [b]
map f xs = go xs
where
go [] = []
go (x:xs) = f x : go xs
{-# INLINE map #-}

We get an inlined version:

go =
  \ (ds_dm7 :: [Char]) ->
case ds_dm7 of wild_B1 {
  [] -> [] @ Char;
  : x_all xs_aln ->
:
  @ Char (toUpper x_all) (A.go xs_aln)
}

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Don Stewart]

ndmitchell:
> Hi
> 
> > Does GHC specialize map?  If it doesn't, then hand crafted version
> > could be faster.
> 
> GHC doesn't specialize map, and a hand-crafted one could be faster -
> but you then wouldn't get foldr/build fusion. In general HLint tries
> to make the code prettier, but sometimes you will need to deviate from
> its suggestions when you've profiled etc. To stop HLint warning you
> just create Hints.hs and include the line "ignore =
> LennartsSuperFastModule.mySpecialisedMap" - full details in the
> manual.
> 
> >> I found so many 'map' re-implementations in Haskell libraries, even in
> >> those, where I thought their programmers must be more experienced than me.
> >> Hm, maybe even in libraries by Neil?
> 
> I can't really be blamed for making mistakes before HLint ;-)
> 

But GHC tends to inline and specialise map, due to:

"map"   [~1] forall f xs.   
map f xs = build (\c n -> foldr (mapFB c f) n xs)

So that,

main = print (map toUpper "haskell")

Yields:

  s :: Addr#
  s = "haskell"#

  letrec
unpack_snX :: Int# -> [Char]
unpack_snX = \ (x :: Int#) ->
case indexCharOffAddr# s x of i { 
  _  -> ($wtoUpper i) (: @ Char) (unpack_snX (+# x 1)
  '\NUL' -> [] @ Char

Which looks inlined and specialised to my eyes.

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

Re: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses

[Rob Hoelz]

I should've included these when I forwarded it, but that was pre-coffee
today. =P

class MyEq p where
  unsafeCompare :: p C(a b) -> p C(c d) -> Bool
  -- more stuff

data FL a C(x z) where
  (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z)
  NilFL :: FL a C(x x)

data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y))
infixr 1 :>

-- I'm not entirely sure on this one, because type witnesses confuse me.
compare_changes_with_old :: (Patchy p) => 
  FL p C(x y)
   -> FL p C(x y)
   -> (FL p :> FL p) C(x y)

C(args...) is a preprocessor macro that expands to args if Darcs is
building with GADT type witnesses.  FORALL(args...) expands to forall
args. under the same condition.

All of the definitions are available at
http://darcs.net/api-doc/doc-index.html as well.

Thanks,
Rob

"Ryan Ingram"  wrote:

> Some questions first:
> What's the type of this function supposed to be?
> What's the type of unsafeCompare?
> How is the data type with NilFL and :>: defined?
> 
>   -- ryan
> 
> On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz  wrote:
> > Forwarding to Haskell Cafe per Eric's suggestion.
> >
> > Begin forwarded message:
> >
> > Date: Sun, 11 Jan 2009 23:01:31 -0600
> > From: Rob Hoelz 
> > To: darcs-de...@darcs.net
> > Subject: [darcs-devel] "Inferred type is less polymorphic than
> > expected" and type witnesses
> >
> >
> > Hello again, Darcs users and developers,
> >
> > As I mentioned in my last e-mail, I'm working on
> > http://bugs.darcs.net/issue291.  It's actually gone pretty well,
> > and I feel I'm just about finished (I've done all but sorting out
> > the changes after leaving the editor), only I've encountered the
> > compiler error you see in the subject of this message. This error
> > only appears when compiling with witnesses. Here's the source for
> > the function that it's complaining about:
> >
> > compare_changes_with_old (x :>: xs) (y :>: ys) =
> >  case compare_changes_with_old xs ys of
> >nx :> ny -> if unsafeCompare x y
> >  then ((x :>: nx) :> ny)
> >  else (NilFL :> (y :>: ys))
> > compare_changes_with_old NilFL NilFL = (NilFL :> NilFL)
> > compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys)
> > compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL)
> >
> > Now, I have two questions:
> >
> > 1) What exactly does this error mean, and how do I get around it?
> > 2) What are witness types, and what are they used for?
> >
> > I will gladly accept links to fine manuals as answers to either
> > question, but simple explanations would be nice. =D  I thought I
> > understood Haskell pretty well, but existentially qualified types
> > have thrown me for a loop.
> >
> > Thanks much,
> > Rob Hoelz
> > ___
> > darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!)
> > darcs-de...@darcs.net
> > http://lists.osuosl.org/mailman/listinfo/darcs-devel
> > ___
> > 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] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses

[Ryan Ingram]

Some questions first:
What's the type of this function supposed to be?
What's the type of unsafeCompare?
How is the data type with NilFL and :>: defined?

  -- ryan

On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz  wrote:
> Forwarding to Haskell Cafe per Eric's suggestion.
>
> Begin forwarded message:
>
> Date: Sun, 11 Jan 2009 23:01:31 -0600
> From: Rob Hoelz 
> To: darcs-de...@darcs.net
> Subject: [darcs-devel] "Inferred type is less polymorphic than
> expected" and type witnesses
>
>
> Hello again, Darcs users and developers,
>
> As I mentioned in my last e-mail, I'm working on
> http://bugs.darcs.net/issue291.  It's actually gone pretty well, and I
> feel I'm just about finished (I've done all but sorting out the
> changes after leaving the editor), only I've encountered the compiler
> error you see in the subject of this message. This error only appears
> when compiling with witnesses. Here's the source for the function
> that it's complaining about:
>
> compare_changes_with_old (x :>: xs) (y :>: ys) =
>  case compare_changes_with_old xs ys of
>nx :> ny -> if unsafeCompare x y
>  then ((x :>: nx) :> ny)
>  else (NilFL :> (y :>: ys))
> compare_changes_with_old NilFL NilFL = (NilFL :> NilFL)
> compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys)
> compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL)
>
> Now, I have two questions:
>
> 1) What exactly does this error mean, and how do I get around it?
> 2) What are witness types, and what are they used for?
>
> I will gladly accept links to fine manuals as answers to either
> question, but simple explanations would be nice. =D  I thought I
> understood Haskell pretty well, but existentially qualified types have
> thrown me for a loop.
>
> Thanks much,
> Rob Hoelz
> ___
> darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!)
> darcs-de...@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
> ___
> 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] ANN: HLint 1.2

[Max Bolingbroke]

2009/1/12 Jan-Willem Maessen :
> On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote:
>
>> No because the current definition are recursive and ghc cannot inline
>> recursive functions.
>>
>> 
>>
>> Then the map can be inlined at the call site and the 'f' inlined into
>> the body of 'go'.
>
> This seems like exactly the sort of mechanical transformation that computers
> do quickly and accurately, and humans get wrong.  Surely it wouldn't be that
> hard for GHC to transform self recursion in this way (possibly subject to
> the condition that the result be worth inlining)?

GHC should indeed be doing so. I'm working (on and off) to work out
some suitable heuristics and put the transformation into ghc -O2.
There are a few wrinkles that still need sorting out, but preliminary
indications are that it decreases the runtime of our standard
benchmark suite, nofib, by 12% or so.

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

[Haskell-cafe] Re: Question about touchForeignPtr

[Simon Marlow]

Patrick Perry wrote:


I have the following code:

IOVector n e = IOVector !ConjEnum !Int (ForeignPtr e)! (Ptr e)! Int!
newtype Vector n e = IOVector n e

unsafeAtVector :: Vector n e -> Int -> e
unsafeAtVector (Vector (IOVector c _ f p inc)) i =
let g = if c == Conj then conjugate else id
in inlinePerformIO $ do
   e  <- peekElemOff p (i*inc)
   io <- touchForeignPtr f
   let e' = g e
   e' `seq` io `seq` return e'
{-# INLINE unsafeAtVector #-}


The Ptr, 'p' is derived from the ForeignPtr, 'f'. For some offset, 'o', it
is defined as:

p = unsafeForeignPtrToPtr f `advancePtr` o

The "touchForeignPtr" is there to keep the garbage collector from 
deallocating
the memory before we have a chance to read 'e'.  My question is the 
following:
Is the `seq` on `io` necessary (from a safety standpoint)?  Or am I just 
being paranoid?


You're just being paranoid - touchForeignPtr returns a (), so seqing it is 
a no-op.


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

Re: [Haskell-cafe] ANN: HLint 1.2

[Jan-Willem Maessen]

On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote:


No because the current definition are recursive and ghc cannot inline
recursive functions.

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

It has to be manually transformed into a version that is not recursive
at the top level:

map :: (a -> b) -> [a] -> [b]
map f = go
 where
   go [] = []
   go (x:xs) = f x : go xs

Then the map can be inlined at the call site and the 'f' inlined into
the body of 'go'.


This seems like exactly the sort of mechanical transformation that  
computers do quickly and accurately, and humans get wrong.  Surely it  
wouldn't be that hard for GHC to transform self recursion in this way  
(possibly subject to the condition that the result be worth inlining)?


[phc did this, and I think it was inherited from Lennart's program  
transformations.]


-Jan-Willem Maessen

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Henning Thielemann]

On Mon, 12 Jan 2009, Neil Mitchell wrote:


Hi


No because the current definition are recursive and ghc cannot inline
recursive functions.



map :: (a -> b) -> [a] -> [b]
map f = go
 where
  go [] = []
  go (x:xs) = f x : go xs

Then the map can be inlined at the call site and the 'f' inlined into
the body of 'go'.


Maybe HLint can make such suggestions ...


HLint would probably just suggest you use a supercompiler*, for which
specialisation such as this is easy
(http://www.cs.york.ac.uk/~ndm/supero). HLint is about making code
prettier,


Actually, I find the 'go' variant prettier, because it clearly shows that 
the 'f' is not "altered" in the recursion.

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Duncan Coutts]

On Mon, 2009-01-12 at 15:06 +0100, Henning Thielemann wrote:


> > It has to be manually transformed into a version that is not recursive
> > at the top level:
> >
> > map :: (a -> b) -> [a] -> [b]
> > map f = go
> >  where
> >go [] = []
> >go (x:xs) = f x : go xs
> >
> > Then the map can be inlined at the call site and the 'f' inlined into
> > the body of 'go'.
> 
> Maybe HLint can make such suggestions ...

I think HLint's philosophy prefers elegant code to performance hacks.

Duncan

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Neil Mitchell]

Hi

>> No because the current definition are recursive and ghc cannot inline
>> recursive functions.
>
>> map :: (a -> b) -> [a] -> [b]
>> map f = go
>>  where
>>   go [] = []
>>   go (x:xs) = f x : go xs
>>
>> Then the map can be inlined at the call site and the 'f' inlined into
>> the body of 'go'.
>
> Maybe HLint can make such suggestions ...

HLint would probably just suggest you use a supercompiler*, for which
specialisation such as this is easy
(http://www.cs.york.ac.uk/~ndm/supero). HLint is about making code
prettier, and only in a few cases does it try for faster (mapM ->
mapM_), but even there its more about avoiding a space leak.

Thanks

Neil

* Of course, HLint (and me) should probably add the disclaimer that
the chances of that working your code as it stands are fairly close to
0 - but the ideas and initial research has been started!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Question about touchForeignPtr

[Duncan Coutts]

On Sun, 2009-01-11 at 17:43 -0800, Patrick Perry wrote:

> The "touchForeignPtr" is there to keep the garbage collector from  
> deallocating the memory before we have a chance to read 'e'.  My
> question is the following:
> Is the `seq` on `io` necessary (from a safety standpoint)?  Or am I  
> just being paranoid?

touchForeignPtr :: ForeignPtr a -> IO ()

There is no need to seq the returned () value. It's the side effect of
touchForeignPtr that provides the guarantee that you're after.

So I think you could use:

 ...
 in inlinePerformIO $ do
e  <- peekElemOff p (i*inc)
touchForeignPtr f
return $! g e

By the way, in your:
IOVector n e = IOVector !ConjEnum !Int (ForeignPtr e)! (Ptr e)! Int!

Do the (ForeignPtr e) and the (Ptr e) point to the same thing? They
appear to be related because you dereference p but touch f.

It used to be the ForeignPtr was slower to dereference than a Ptr and so
caching it like this could make it faster (but then requires lots of
careful thought about touchForeignPtr). These days ForeignPtr is just as
fast and so you can use withForeignPtr and never have to worry about
touchForeignPtr. You'll notice ByteString works this way.

Duncan

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

Re: [Haskell-cafe] ANN: HLint 1.2

[Henning Thielemann]

On Mon, 12 Jan 2009, Duncan Coutts wrote:


On Mon, 2009-01-12 at 01:02 +0100, Lennart Augustsson wrote:

Does GHC specialize map?  If it doesn't, then hand crafted version
could be faster.


No because the current definition are recursive and ghc cannot inline
recursive functions.

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

It has to be manually transformed into a version that is not recursive
at the top level:

map :: (a -> b) -> [a] -> [b]
map f = go
 where
   go [] = []
   go (x:xs) = f x : go xs

Then the map can be inlined at the call site and the 'f' inlined into
the body of 'go'.


Maybe HLint can make such suggestions ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: HLint 1.2

[Duncan Coutts]

On Mon, 2009-01-12 at 01:02 +0100, Lennart Augustsson wrote:
> Does GHC specialize map?  If it doesn't, then hand crafted version
> could be faster.

No because the current definition are recursive and ghc cannot inline
recursive functions.

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

It has to be manually transformed into a version that is not recursive
at the top level:

map :: (a -> b) -> [a] -> [b]
map f = go
  where
go [] = []
go (x:xs) = f x : go xs

Then the map can be inlined at the call site and the 'f' inlined into
the body of 'go'.

Obviously this is not quite the same as specialising map since it's per
use not per-function being mapped. Though specialisation would be just:

mapFoo = map foo

I'm not sure if you'd need
{-# NOINLINE mapFoo #-}

This is exactly how the ghc definitions for foldr and foldl work:

foldr k z xs = go xs
 where
   go [] = z
   go (y:ys) = y `k` go ys

foldl f z xs = lgo z xs
 where
lgo z [] =  z
lgo z (x:xs) = lgo (f z x) xs

Duncan

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

[Haskell-cafe] Re: ANN: HLint 1.2

[Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara]

Neil Mitchell escribió:
> Hi
> 
>> Does GHC specialize map?  If it doesn't, then hand crafted version
>> could be faster.
> 
> GHC doesn't specialize map, and a hand-crafted one could be faster -
> but you then wouldn't get foldr/build fusion. In general HLint tries
> to make the code prettier, but sometimes you will need to deviate from
> its suggestions when you've profiled etc. To stop HLint warning you
> just create Hints.hs and include the line "ignore =
> LennartsSuperFastModule.mySpecialisedMap" - full details in the
> manual.
> 

I am really happy with HLint. Being relatively new to haskell world, I
tend to be slow in finding ready-made solutions, or using folds fot
recursive tasks.

HLint 1.0 discovers `on` for me, and only for that I will be infinitely
grateful.

Now, if HLint 1.2 helps me with the map/fold understanding, I will be
'continuous infinitely' grateful (although real numbers are not
representable!)

Best regards,

Zara

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

Re: [Haskell-cafe] version conflict on Hackage

[Duncan Coutts]

On Mon, 2009-01-12 at 13:21 +0100, Henning Thielemann wrote:
> I repeatedly encounter the following versioning problem on Hackage:
> There is a package A with version 1.0.
> I upload a package B which imports A.
> Thus B is bound to A-1.0
> Now a new version of A is uploaded, say 1.0.1.
> then I upload package C which depends both on A and B.
> However C is bound to the new A-1.0.1, which gives conflicts with the 
> interface of B.
> All packages are sane. Both B and C work with either A-1.0 or A-1.0.1,
> but they must use the same version.

The package builder on hackage is broken for this reason, amongst
others.

> Currently I'm forced to upload many packages with different versions, 
> although nothing really changed.
> Maybe the most easiest fix to this problem is to let maintainers of a 
> package allow to trigger re-configuration and re-compilation of a package.

The plan with the new hackage server is that we have a smarter build
client (cabal-install) that does install plans and so always installs
consistent versions of packages.

> I would also like to flag package versions that people can safely ignore, 
> because there was a flaw in package dependencies.

There is a mechanism for doing this but no UI yet.

> On the other hand there are packages that are useful, but can no
> longer be compiled on Hackage, e.g. compatibility packages for older
> versions of GHC.

Right, we should leave those alone.

Duncan

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

[Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses

[Rob Hoelz]

Forwarding to Haskell Cafe per Eric's suggestion.

Begin forwarded message:

Date: Sun, 11 Jan 2009 23:01:31 -0600
From: Rob Hoelz 
To: darcs-de...@darcs.net
Subject: [darcs-devel] "Inferred type is less polymorphic than
expected" and type witnesses


Hello again, Darcs users and developers,

As I mentioned in my last e-mail, I'm working on
http://bugs.darcs.net/issue291.  It's actually gone pretty well, and I
feel I'm just about finished (I've done all but sorting out the
changes after leaving the editor), only I've encountered the compiler
error you see in the subject of this message. This error only appears
when compiling with witnesses. Here's the source for the function
that it's complaining about:

compare_changes_with_old (x :>: xs) (y :>: ys) =
  case compare_changes_with_old xs ys of
nx :> ny -> if unsafeCompare x y
  then ((x :>: nx) :> ny)
  else (NilFL :> (y :>: ys))
compare_changes_with_old NilFL NilFL = (NilFL :> NilFL)
compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys)
compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL)

Now, I have two questions:

1) What exactly does this error mean, and how do I get around it?
2) What are witness types, and what are they used for?

I will gladly accept links to fine manuals as answers to either
question, but simple explanations would be nice. =D  I thought I
understood Haskell pretty well, but existentially qualified types have
thrown me for a loop.

Thanks much,
Rob Hoelz
___
darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!)
darcs-de...@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Maintaining laziness

[Henning Thielemann]

On Mon, 12 Jan 2009, Jan Christiansen wrote:


Hi,

Although it seems to be overkill for a single module - How about a 
cabalized version on Hackage and a darcs repository? It would simplify 
using and updating it.


I am not sure whether this would be a good idea. The original version makes a 
lot of suggestions which are not satisfiable but it is not at all trivial to 
decide which are satisfiable and which are not. I have rewritten StrictCheck 
from scratch to overcome this problem. But the current implementation is not 
presentable right now and I have no formal prove that the criterion that I am 
using is correct.


As I said, the current version is already very useful. I have applied it 
to several basic functions and found a lot to improve.

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

Re: [Haskell-cafe] Re: System.CPUTime and picoseconds

[Tony Finch]

On Mon, 12 Jan 2009, ChrisK wrote:
>
> Lennart is right that 1 picosecond accuracy is absurd compared to all
> the jitters and drifts in anything but an actual atomic clock in your
> room.  But since CPUs tick faster than nanosecond the CPUTime needs
> better than 1 nanosecond granularity.  I agree with Lennart — I also
> want an Integral type; it keeps the granularity constant and avoids all
> the pitfalls of doing math with a Double.  Out of simplicity I can see
> why the granularity was set to 1 picosecond as it is slightly easier to
> specify than 100 picosecond or 10 picosecond or 1/60 nanosecond (hmmm...
> arcnanosecond?).

The FreeBSD kernel uses a 64+64 bit fixed point type to represent time,
where the integer part is a normal Unix time_t. The fractional part is
64 bits wide in order to be able to represent multi-GHz frequencies
precisely.

http://phk.freebsd.dk/pubs/timecounter.pdf

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
TYNE DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST 7 TO SEVERE GALE 9
DECREASING 5 OR 6 LATER. MODERATE TO VERY ROUGH, DECREASING SLIGHT TO ROUGH
LATER. OCCASIONAL RAIN. MODERATE OR GOOD.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Maintaining laziness

[Jan Christiansen]

Hi,

Although it seems to be overkill for a single module - How about a  
cabalized version on Hackage and a darcs repository? It would  
simplify using and updating it.


I am not sure whether this would be a good idea. The original version  
makes a lot of suggestions which are not satisfiable but it is not at  
all trivial to decide which are satisfiable and which are not. I have  
rewritten StrictCheck from scratch to overcome this problem. But the  
current implementation is not presentable right now and I have no  
formal prove that the criterion that I am using is correct.


Your StrictCheck is really tough! I'm currently checking my  
routines from
 http://hackage.haskell.org/packages/archive/utility-ht/0.0.1/doc/ 
html/Data-List-HT.html
  which I designed especially with laziness in mind - and I found a  
lot of laziness breakers using StrictCheck!


 However now I found an example where it probably proposes  
something inefficient:


So what it proposes is essentially that one should first check the  
length of the lists without looking at the contents.  
[undefined,undefined] can never be a prefix of [undefined].  
However, first constructing the list spine seems to be inefficient.


I know about this problem. It is mentioned in the paper about  
StrictCheck. I haven't worked on this right now. With respect to  
least-strictness I would say the tool is right. But it is probably  
not the kind of advise one wants. When I am sure that I can handle  
the other problem I will take a look at this one.


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

[Haskell-cafe] version conflict on Hackage

[Henning Thielemann]

I repeatedly encounter the following versioning problem on Hackage:
There is a package A with version 1.0.
I upload a package B which imports A.
Thus B is bound to A-1.0
Now a new version of A is uploaded, say 1.0.1.
then I upload package C which depends both on A and B.
However C is bound to the new A-1.0.1, which gives conflicts with the interface 
of B.
All packages are sane. Both B and C work with either A-1.0 or A-1.0.1,
but they must use the same version.

Currently I'm forced to upload many packages with different versions, 
although nothing really changed.
Maybe the most easiest fix to this problem is to let maintainers of a 
package allow to trigger re-configuration and re-compilation of a package.


I would also like to flag package versions that people can safely ignore, 
because there was a flaw in package dependencies. On the other hand there 
are packages that are useful, but can no longer be compiled on Hackage, 
e.g. compatibility packages for older versions of GHC.

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

[Haskell-cafe] Error building Sdf2Haskell

[rodrigo.bonifacio]

Hi all,
I'm trying to build the Sdf2Haskell library. However, I've got the following problem:
Making all in generatorlocate: illegal option -- nusage: locate [-0Scims] [-l limit] [-d database] pattern ...default database: `/var/db/locate.database' or $LOCATE_PATHmake Sdf.tbllocate: illegal option -- nusage: locate [-0Scims] [-l limit] [-d database] pattern ...default database: `/var/db/locate.database' or $LOCATE_PATHmake[2]: `Sdf.tbl' is up to date.make Sdf.hslocate: illegal option -- nusage: locate [-0Scims] [-l limit] [-d database] pattern ...default database: `/var/db/locate.database' or $LOCATE_PATHmake[2]: `Sdf.hs' is up to date.make SyntaxATermConvertibleInstances.hslocate: illegal option -- nusage: locate [-0Scims] [-l limit] [-d database] pattern ...default database: `/var/db/locate.database' or $LOCATE_PATHmake[2]: `SyntaxATermConvertibleInstances.hs' is up to date.ghc -fglasgow-exts -fallow-overlapping-instances -fallo
 w-undecidable-instances -package data -package lang -i/Users/rbonifacio/tmp/strafunski/Sdf2Haskell-2.3/../StrategyLib/library:/Users/rbonifacio/tmp/strafunski/Sdf2Haskell-2.3/../StrategyLib/models/drift-default: -package util -i/Users/rbonifacio/tmp/strafunski/Sdf2Haskell-2.3/../ATermLib/library:/Users/rbonifacio/tmp/strafunski/Sdf2Haskell-2.3/../StrategyLib/examples/haskell: --make Sdf2Haskell.hs -o Sdf2Haskell: unknown package: datamake[1]: *** [Sdf2Haskell] Error 1make: *** [all-recursive] Error 1
I guess that the main problem is the *unknown data package*. Does anybody know where can I find such a package?
The version of GHC installed in my environment is 6.8.3.
Thanks in advance.
Rodrigo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Computer time, independent of date

[Mauricio]

patients, I wanted to be sure not to save wrong
information. It wouldn't matter if the clock is
saying we are on XVII century, as long as 10 seconds
would never be 10.1.


What are the interval durations you need to measure?
Since they are from equipment, what is the spec?


I read from serial port. When the equipment was
available for testing, we measured the output to
be a few thowsand bytes/second. The program is
supposed to run in Windows computers at physicians
offices (and their only requirement is to be able
to run windows and have a serial port). Errors of
1 byte per second would be acceptable, even if they
accumulate.

I have no equipment specs and, right now, no
equipment to test. (Yes, I know this is crazy.) So,
I need to know what kind of problems I may expect,
so I'm able to deal with them.

Thanks,
Maurício

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

Re: [Haskell-cafe] Re: System.CPUTime and picoseconds

[ChrisK]

Neil Davies wrote:
I've found the pico second accuracy useful in working with 'rate 
equivalent' real time systems. Systems where the individual timings 
(their jitter) is not critical but the long term rate should be accurate 
- the extra precision helps with keeping the error accumulation under 
control.


When you are selling something (like data bandwidth) and you are pacing 
the data stream on a per packet basis you definitely want any error to 
accumulate slowly - you are in the 10^10 events per day range here.


Neil



Now I am posting just because I like to look at the time scales.

A rate of 10^10 per Day is a period of 8.64 microseconds.

If you want to slip only 1 period per year then you need a fractional accuracy 
of 2.74 * 10^-13.  In one day this is a slip of 23.7 nanoseconds.


So atomic time radio synchronization is too inaccurate. I have seen GPS 
receivers that claim to keep the absolute time to within 100 nanoseconds.


Lennart is right that 1 picosecond accuracy is absurd compared to all the 
jitters and drifts in anything but an actual atomic clock in your room.  But 
since CPUs tick faster than nanosecond the CPUTime needs better than 1 
nanosecond granularity.  I agree with Lennart — I also want an Integral type; it 
keeps the granularity constant and avoids all the pitfalls of doing math with a 
Double.  Out of simplicity I can see why the granularity was set to 1 picosecond 
as it is slightly easier to specify than 100 picosecond or 10 picosecond or 1/60 
nanosecond (hmmm... arcnanosecond?).


Maybe Haskell should name the "1/60 nanosecond" unit something clever and create 
a new Time submodule using it for April 1st.  [ Base 60 is the real standard: 
http://en.wikipedia.org/wiki/Babylonian_mathematics has an 1800 B.C. tablet with 
the (sqrt 2) in base 60 as (1).(24)(51)(10) ]


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

[Haskell-cafe] Re: System.CPUTime and picoseconds

[Mauricio]

Aren't Doubles evil? Integer is a nice type, Haskell
filosofy compliant. Doubles are not CDoubles, IEEE, infinite
precision or anything long term meaninfull. (Warning:
non-expert opinion.)

I've found the pico second accuracy useful in working with 'rate 
equivalent' real time systems. Systems where the individual timings 
(their jitter) is not critical but the long term rate should be accurate 
- the extra precision helps with keeping the error accumulation under 
control.


When you are selling something (like data bandwidth) and you are pacing 
the data stream on a per packet basis you definitely want any error to 
accumulate slowly - you are in the 10^10 events per day range here.


Neil


On 12 Jan 2009, at 00:00, Lennart Augustsson wrote:

On Sun, Jan 11, 2009 at 8:28 PM, ChrisK 
 wrote:
An Double or Int64 are both 8 bytes and counts with picoseconds 
precision
for 2.5 hours to 106 days.  Going to 12 byte integer lets you count 
to 3.9

billion years (signed).  Going to 16 byte integer is over 10^38 years.

Lennart Augustsson wrote:


A double has 53 bits in the mantissa which means that for a running
time of about 24 hours you'd still have picoseconds.  I doubt anyone
cares about picoseconds when the running time is a day.


The above is an unfounded claim about the rest of humanity.


It's not really about humanity, but about physics.  The best known
clocks have a long term error of about 1e-14.
If anyone claims to have made a time measurement where the accuracy
exceeds the precision of a double I will just assume that this person
is a liar.

For counting discrete events, like clock cycles, I want something like
Integer or Int64.  For measuring physical quantities, like CPU time,
I'll settle for Double, because we can't measure any better than this
(this can of course become obsolete, but I'll accept that error).

 -- Lennart
___
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: System.CPUTime and picoseconds

[Neil Davies]

I've found the pico second accuracy useful in working with 'rate  
equivalent' real time systems. Systems where the individual timings  
(their jitter) is not critical but the long term rate should be  
accurate - the extra precision helps with keeping the error  
accumulation under control.


When you are selling something (like data bandwidth) and you are  
pacing the data stream on a per packet basis you definitely want any  
error to accumulate slowly - you are in the 10^10 events per day range  
here.


Neil


On 12 Jan 2009, at 00:00, Lennart Augustsson wrote:

On Sun, Jan 11, 2009 at 8:28 PM, ChrisK  
 wrote:
An Double or Int64 are both 8 bytes and counts with picoseconds  
precision
for 2.5 hours to 106 days.  Going to 12 byte integer lets you count  
to 3.9
billion years (signed).  Going to 16 byte integer is over 10^38  
years.


Lennart Augustsson wrote:


A double has 53 bits in the mantissa which means that for a running
time of about 24 hours you'd still have picoseconds.  I doubt anyone
cares about picoseconds when the running time is a day.


The above is an unfounded claim about the rest of humanity.


It's not really about humanity, but about physics.  The best known
clocks have a long term error of about 1e-14.
If anyone claims to have made a time measurement where the accuracy
exceeds the precision of a double I will just assume that this person
is a liar.

For counting discrete events, like clock cycles, I want something like
Integer or Int64.  For measuring physical quantities, like CPU time,
I'll settle for Double, because we can't measure any better than this
(this can of course become obsolete, but I'll accept that error).

 -- Lennart
___
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] [ANNOUNCE] First release candidate of darcs 2.2.

[Eric Kow]

Dear Haskellers,

I would like to forward this announcement on behalf of Petr Ročkai
(the current darcs Release Manager).

Darcs 2.2 is scheduled for release in 2009-01-15, only three days from
now!  This is the first of our biannual time-based releases.  We hope
you'll like it, and to help us ensure that you will like it, please help
us test our the release candidate.

Thanks!

Eric

Petr's words follow:

8<-
I am pleased to announce that darcs 2.2 is coming along nicely. I would like to
ask everyone to give a ride to darcs 2.2, release candidate 1. This release
again comes in two flavours:

1) The source tarball, http://repos.mornfall.net/darcs/darcs-2.2.0rc1.tar.gz,
which can be built using the traditional autoconf-based buildsystem. This is
the fully supported version. After downloading and unpacking, you can issue:

$ ./configure
$ make
$ ./darcs --version

or

# make install

More detailed instructions inside the tarball (file README).

2) Cabalised source. You can either download a tarball from
http://repos.mornfall.net/darcs/darcs-2.1.99.0.tar.gz and build manually (see
the build instructions in README inside the tarball), or, alternatively, you
can use cabal-install to obtain a copy (the release candidate is now available
on hackage):

$ cabal update
$ cabal install darcs

This should give you a darcs binary in ~/.cabal/bin -- you should probably add
that to your PATH.

This is a preliminary changelog since version 2.1.2 (released last November):

  * In interactive record, it is now possible to get a list of
currently selected hunks (command 'l'). (Christian Kellermann)
  * It is now possible to specify --in-reply-to when using darcs send, to
generate correct references in the mail header.  (Pavel Shramov)
  * New repositories with --no-pristine-tree can no longer be
created. This only has effect on legacy darcs-1 repositories.
  * Improvements in Windows support. (Salvatore Insalaco)
  * Performance improvements in `darcs repair` and robustness improvements in
`darcs check`. (Petr Ročkai)

  * Extensive manual and online help improvements. (Trent W. Buck)

  * Support for GHC 6.10.

  * Overhaul of the make-based build system. (Trent W. Buck)
  * Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr
Ročkai, Gwern Branwen)

  * First stab at libdarcs -- when building through Cabal, all of darcs
implementation is now exposed in modules. No API guarantees
whatsoever. (Eric Kow)
  * Additions to Haddock documentation of the existing darcs modules for
improved development experience.

  * Improvements in the testing infrastructure. (Christian Kellermann, Gwern
Branwen)

  * Low-level optimisations in filesystem code. (Ganesh Sittampalam)
  * Numerous major and minor bug fixes, refactorings and cleanups by David
Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore
Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier
Lamers, Ganesh Sittampalam, Petr Ročkai.

Preliminary list of issues that have been fixed in darcs since version 2.1.2:

1223sporadic init.sh test failure (2.1.1rc2+472)
525 amend-record => darcs patches show duplicate additions
1247make TAGS is broken
1273renameFile: does not exist (No such file or directory)
1165get should print last gotten tag
12492.1.2 (+ 342 patches) local drive detection on Windows error
1238wish: darcs help setpref should list all prefs
1199Backup files darcs added after external merge
1043pull => mergeAfterConflicting failed in geteff (2.0.2+)
1117Whatsnew should warn on non-recorded files
1101darcs send --cc recipient not included in success message

Thanks to Thorkil Naur for compiling this list.

I would like to thank all contributors -- developers, testers, bystanders --
for helping darcs get along further. It's been hard times recently for darcs,
as many of you probably know. Nevertheless, we are regaining confidence in
future darcs development. No way are we going to leave darcs fall by the
road. I am sure that this one time, I speak for everyone in our developer and
user community.

Yours,
   Petr.

-- 
Eric Kow 
PGP Key ID: 08AC04F9


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

[Haskell-cafe] Re: concurrent haskell: thread priorities

[Simon Marlow]

Neal Alexander wrote:

Simon Marlow wrote:

Neal Alexander wrote:

Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and 
still

be slackers) if we allow marked green threads to be strictly
associated with a specific OS thread (forkChildIO?).


I think you want the GHC-only GHC.Conc.forkOnIO

GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't 
attach them to the same OS thread.


But it does attach the thread to a particular "virtual CPU" in the GHC 
RTS (we call them "capabilities"), with the intention that a virtual 
CPU corresponds more or less to a real CPU core.


Cheers,
Simon


Yea, but you still have the problem with FFI that uses TLS don't you? 
What about having a forkOnOS version with processor affinity? Or is 
there a way to "upgrade" a thread created with forkOnIO to Bound.


Yes, forkOnOS would be possible (you can write it yourself using the 
primitives, in fact).


I have a thread with soft real-time requirements that cooperatively 
yields and uses thread local state. Right now there just doesn't seem to 
be any options.


Right - real-time and priorities are things that we don't do at the moment, 
unfortunately.


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

[Haskell-cafe] Re: concurrent haskell: thread priorities

[Simon Marlow]

Don Stewart wrote:

marlowsd:

Neal Alexander wrote:

Thomas DuBuisson wrote:

   It seems like we could get some priority based scheduling (and still
   be slackers) if we allow marked green threads to be strictly
   associated with a specific OS thread (forkChildIO?).


I think you want the GHC-only GHC.Conc.forkOnIO

GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't 
attach them to the same OS thread.
But it does attach the thread to a particular "virtual CPU" in the GHC RTS 
(we call them "capabilities"), with the intention that a virtual CPU 
corresponds more or less to a real CPU core.


Every time Simon responds on questions of parallelism and the GHC
runtime, I learn something. That indicates to me that we've got a 'bus
error' situation with how to effectively use the smp runtime. 


Simon: time for a multicore FAQ wiki page to gather this knowledge, like
we did for the performance tips? Somewhere to paste these insights?


Sure, that would be great.  One slight problem is that I'm still learning 
myself how to use parallelism effectively, and the RTS is still changing 
rapidly.  We have a paper in the works that should serve as a good overview 
of the implementation, but a wiki page would be more suitable for users. 
If nobody else starts one, I'll try to get to it in the next few weeks.


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

Re: [Haskell-cafe] ANN: HLint 1.2

[Neil Mitchell]

Hi

> Does GHC specialize map?  If it doesn't, then hand crafted version
> could be faster.

GHC doesn't specialize map, and a hand-crafted one could be faster -
but you then wouldn't get foldr/build fusion. In general HLint tries
to make the code prettier, but sometimes you will need to deviate from
its suggestions when you've profiled etc. To stop HLint warning you
just create Hints.hs and include the line "ignore =
LennartsSuperFastModule.mySpecialisedMap" - full details in the
manual.

>> I found so many 'map' re-implementations in Haskell libraries, even in
>> those, where I thought their programmers must be more experienced than me.
>> Hm, maybe even in libraries by Neil?

I can't really be blamed for making mistakes before HLint ;-)

Thanks

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

[Haskell-cafe] Re: how to link to external documentation with haddock ?

[Dominic Steinitz]

minh thu  gmail.com> writes:

http://www.haskell.org/haskellwiki/Haddock/FAQ

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