date:20090113


Hi.

I have some doubts about errno handling in a Concurrent Haskell program.

Let's suppose that GHC non threaded runtime is used, so that each 
Haskell thread is bound to an OS thread.


Let's suppose there are two threads running (`A` and `B`).
Thread `A` calls a function `f`, that, in turn, calls via FFI a C 
function `c_f`.


Function `c_f` fails, settings errno; however the GHC scheduler suspends 
execution of thread `A` and switch to thread `B`, before the current 
value of errno is read.


Now, let's suppose thread `B` calls a function `g`, that, in turn, calls 
via FFI a C function `c_g`.

Function `c_g`, too, fails, setting errno.


Is this possible?


P.S.:
I have found this is C.Foreign.Error.hs, in base package (not the latest 
version):


throwErrnoIfRetry:: (a - Bool) - String - IO a - IO a
throwErrnoIfRetry pred loc f  =
  do
res - f
if pred res
  then do
err - getErrno
if err == eINTR
  then throwErrnoIfRetry pred loc f
  else throwErrno loc
  else return res

This function calls getErrno two times.
Is this safe?

Why the throwErrno function does not accept errno as parameter?



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

[Haskell-cafe] Re: Issues with posix-realtime package


Galchin, Vasili ha scritto:

[...]
I would like to help to develope any wrappers around POSIX API.


 ^^^ you are suggesting to change current wrapper API?



No, but I don't understand why to link code that seems to be not used.

P.S.: is the problem I have reported riproducible?
  I'm on Linux Debian Lenny.



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

[Haskell-cafe] Slow Text.JSON parser

2009-01-13 Thread Levi Greenspan

Dear list members,

I tried Text.JSON from hackage and did an initial test to see how well
it performs. I created a single JSON file of roughly 6 MB containing a
single JSON array with 30906 JSON objects and used the following code
to parse it:


module Main where

import System.IO
import Data.Time.Clock
import System.Environment
import Text.Printf
import Text.JSON

parse s = do
start - getCurrentTime
let !len = decode s
end - getCurrentTime
print len
printf Elapsed time = %s\n (show $ diffUTCTime end start)
where
decode s = case decodeStrict s of
Ok (JSArray a) - length a
_ - -1

main = do
file - getArgs = return . head
withFile file ReadMode (\h - hGetContents h = parse)



The outcome was something like:

30906
Elapsed time = 2.902755s

on my 2GHz core 2 duo.

Another Java-based JSON parser (Jackson:
http://www.cowtowncoder.com/hatchery/jackson/index.html) gives me:

30906
Elapsed time = 480 ms

Now I wonder why Text.JSON is so slow in comparison and what can be
done about it. Any ideas? Or is the test case invalid?

Thanks,
Levi

---
The Java code for the Jackson test is:

import org.codehaus.jackson.JsonParser;
import org.codehaus.jackson.JsonFactory;
import org.codehaus.jackson.map.JsonTypeMapper;
import org.codehaus.jackson.map.JsonNode;

import java.io.File;

class Test {

public static void main(String[] args) throws Exception {
final long start = System.currentTimeMillis();
final JsonTypeMapper mapper = new JsonTypeMapper();
final JsonParser parser = new
JsonFactory().createJsonParser(new File(args[0]));
final JsonNode root = mapper.read(parser);
final long end = System.currentTimeMillis();
System.out.println(root.size());
System.out.println(String.format(Elapsed time = %d ms, end - start));
}
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANN: HLint 1.2

2009-01-13 Thread Simon Marlow


Max Bolingbroke wrote:

2009/1/12 Jan-Willem Maessen jmaes...@alum.mit.edu:

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.


!!!

That's a surprising result - have you looked closely at the places where 
the transformation is having a big effect to see what's going on?


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

[Haskell-cafe] Re: errno handling in concurrent haskell

2009-01-13 Thread Simon Marlow


Manlio Perillo wrote:


I have some doubts about errno handling in a Concurrent Haskell program.

Let's suppose that GHC non threaded runtime is used, so that each 
Haskell thread is bound to an OS thread.


Let's suppose there are two threads running (`A` and `B`).
Thread `A` calls a function `f`, that, in turn, calls via FFI a C 
function `c_f`.


Function `c_f` fails, settings errno; however the GHC scheduler suspends 
execution of thread `A` and switch to thread `B`, before the current 
value of errno is read.


Now, let's suppose thread `B` calls a function `g`, that, in turn, calls 
via FFI a C function `c_g`.

Function `c_g`, too, fails, setting errno.


Is this possible?


It's safe, we save the value of errno when a Haskell thread is descheduled, 
and restore it when it is scheduled again.  We do the same on Windows for 
GetLastError().



P.S.:
I have found this is C.Foreign.Error.hs, in base package (not the latest 
version):


throwErrnoIfRetry:: (a - Bool) - String - IO a - IO a
throwErrnoIfRetry pred loc f  =
  do
res - f
if pred res
  then do
err - getErrno
if err == eINTR
  then throwErrnoIfRetry pred loc f
  else throwErrno loc
  else return res

This function calls getErrno two times.
Is this safe?


yes


Why the throwErrno function does not accept errno as parameter?


because it reads the global errno.

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

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

2009-01-13 Thread Yitzchak Gale

Andrew Coppin wrote:
 Does it suggest unfoldr too?

I think Neil's idea to have this customizable is a good one.
It's often a matter of taste.

I would rarely want to use unfoldr, and I wouldn't want HList
to bother me about it. Instead, I prefer to use iterate for both
of Andrew's examples:

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

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

convert b = map (`mod` b) . takeWhile ( 0) . iterate (`div` b)

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

heap_to_list = map heap_top . takeWhile (not . heap_empty) .
   iterate heap_delete_top

Here is one case where I actually do use unfoldr:

-- Mine free-form user input for occurrences of a data type
readMany = unfoldr $ listToMaybe . concatMap reads . tails

ghci readMany The numbers are 3, 7, and 42. :: [Int]
[3,7,42]

But I don't believe HLint should be expected to come up with
something like that. It's quite rare.

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

Re: [Haskell-cafe] Slow Text.JSON parser

2009-01-13 Thread Ketil Malde

Levi Greenspan greenspan.l...@googlemail.com writes:

 Now I wonder why Text.JSON is so slow in comparison and what can be
 done about it. Any ideas? Or is the test case invalid?

I haven't used JSON, but at first glance, I'd blame String IO.  Can't
you decode from ByteString?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
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

2009-01-13 Thread Mauricio

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


One nice thing would be to write something like rlwrap
that would work everywhere Haskell does. Even more
sofisticated behavior could come from some comunication
from the api, using standard OS facilities (like a file
with an updated list of completions, or something more
clever).

(For those interested: rlwrap is available in cygwin.
It used to work very well on old ghci, when line
editing wasn't available.)

Best,
Maurício

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

[Haskell-cafe] Re: ANN: HLint 1.2

2009-01-13 Thread Max Bolingbroke

2009/1/13 Simon Marlow marlo...@gmail.com:
 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.

 !!!

 That's a surprising result - have you looked closely at the places where the
 transformation is having a big effect to see what's going on?

Yes, it is rather better than I expected :-)

The main gains seem to come from specialising higher-order functions
on particular arguments, like we saw earlier in this thread. There
seem to be a number of suitable functions in the standard library that
aren't written in static-argument-transformed (SATed) style.

Another gain comes from the nofib program atom, which has a function
a lot like this:

f x y z = (x, y, z) : f x y z

Once this is SATed it becomes a much better function:

f = let f' = (x, y, z) : f'
 in f'

Which decreases runtime of atom by 97% :-)

The catch is that things written in this style can actually be worse
than their lambda-lifted brethren. This happens for 3 main reasons:

1) SATed functions tend to have case liberation applied to them
instead of constructor specialisation. Case liberation kind of sucks
in comparison to constructor specialisation, so bad things happen
(increased allocations and code size)
2) Carrying around a single variable in the SAT closure just adds
indirection to the generated code with no benefits, so it's better to
remove that indirection (by lambda lifting) just before going to STG -
but be careful not to change the unfolding!
3) More SATing means more expressions are loop invariant. This is
usually a good thing, but if you float a loop-invariant out of a cold
branch of a recursive function (a branch that is actually only
entered once dynamically) then you end up eagerly allocating a closure
for the loop-invariant thing which may never be entered. This is sort
of a bug in our current float-out pass.

Like I said, I'm working on improving the situation with 1 and 2,
which need to be resolved to iron out some of the bad cases in nofib.
I need to find time to take a look at this though.

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

[Haskell-cafe] Re: errno handling in concurrent haskell


Simon Marlow ha scritto:

Manlio Perillo wrote:


I have some doubts about errno handling in a Concurrent Haskell program.

Let's suppose that GHC non threaded runtime is used, so that each 
Haskell thread is bound to an OS thread.


Let's suppose there are two threads running (`A` and `B`).
Thread `A` calls a function `f`, that, in turn, calls via FFI a C 
function `c_f`.


Function `c_f` fails, settings errno; however the GHC scheduler 
suspends execution of thread `A` and switch to thread `B`, before the 
current value of errno is read.


Now, let's suppose thread `B` calls a function `g`, that, in turn, 
calls via FFI a C function `c_g`.

Function `c_g`, too, fails, setting errno.


Is this possible?


It's safe, we save the value of errno when a Haskell thread is 
descheduled, and restore it when it is scheduled again.  We do the same 
on Windows for GetLastError().




Thanks.

I was just replying to the message, after having read the code of the 
scheduler.




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

[Haskell-cafe] The problem with Monads...

2009-01-13 Thread Rafael Gustavo da Cunha Pereira Pinto

Last night I was thinking on what makes monads so hard to take, and came to
a conclusion: the lack of a guided tour on the implemented monads.

Let's take the Writer monad documentation: all it says is:

Inspired by the paper Functional Programming with Overloading and
Higher-Order Polymorphism,
Mark P Jones (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
  Advanced School of Functional Programming, 1995.

SO WHAT?

The best approach is the Part II of the All About Monads tutorial. There
you have the almost ideal approach, except that the examples are just thrown
there, with no step-by-step explanation.

Of course one could copy, paste and run it, but this gives pretty much a is
it right?'  feeling. Questions like if a Reader is an application, why
don't use a regular function instead? or what bind means for a State
monad?.

I will try to work on a Part II extended version on my vacations... maybe
a WikiMonad... or MonadPedia... :-)

After all, it is my duty as a haskell noob to write another monad tutorial!
:D

Cheers!

-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Slow Text.JSON parser

ketil:
 Levi Greenspan greenspan.l...@googlemail.com writes:
 
  Now I wonder why Text.JSON is so slow in comparison and what can be
  done about it. Any ideas? Or is the test case invalid?
 
 I haven't used JSON, but at first glance, I'd blame String IO.  Can't
 you decode from ByteString?
 

Text.JSON was never optimised for performance. It was designed for small
JSON objects. For things above 1M I'd suggest using Data.Binary (or a
quick JSON encoding over bytestrings). Shouldn't be too hard to prepare.

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

2009-01-13 Thread Judah Jacobson

On Tue, Jan 13, 2009 at 6:03 AM, Mauricio briqueabra...@yahoo.com 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

 One nice thing would be to write something like rlwrap
 that would work everywhere Haskell does. Even more
 sofisticated behavior could come from some comunication
 from the api, using standard OS facilities (like a file
 with an updated list of completions, or something more
 clever).

 (For those interested: rlwrap is available in cygwin.
 It used to work very well on old ghci, when line
 editing wasn't available.)

This does sound useful; the main difficulty is that when a program has
stdin piped from another process it may behaved differently.  For
example, ghci uses block buffering and doesn't print its prompt when
stdin doesn't appear to be a terminal.  The solution on POSIX is
probably to use some sort of pseudo-terminal support; I don't know
what the right thing to do on Windows is.

The following post discusses those issues in a little more detail:
http://www.haskell.org/pipermail/haskell-cafe/2008-May/042342.html

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

[Haskell-cafe] real haskell difficulties (at least for me)

2009-01-13 Thread Regis Saint-Paul

Hi, 

Ive seen many times the monad topic coming around on the cafe and plentiful
tutorials on monads have been published. However, as a complete Haskell
newbie coming from OOP, I felt monads were not particularly difficult to
grasp, and very exciting to work with. 

During my experiments with Haskell so far, the main problems I kept bumping
into were not related to the language but to its libraries: their
compilation and installation. Unfortunately, this topic has not received
nearly as much attention. I was unable to find a comprehensive tutorial on
how to deal with the variety of problems I get when trying to install
Hackage packages. This turned out to be (and still is) THE main source of
wasted time and headaches. And worse, unlike type problems, these are not
interesting ones to solve. 

Thus, as a beginner, the package management is what is really getting in the
way of switching to Haskell--not the language. Even books like Real World
Haskell (otherwise excellent) ignore entirely the topic. Cabal and
Cabal-install are clearly wonderful applications that make installing most
packages very straightforward. Unfortunately, whenever this standard
method for package installation fails (or when it is not available as with,
e.g., gtk2hs), I find myself in complete disarray. 

Below are some of the questions and issues I faced regarding package
management: 

- For a number of packages, cabal-install gets stuck and has to be killed. I
assume this is due to some difficulties in solving the dependencies and it
is fine, not all can be automated and cabal-install is not responsible for
poor packages. But the question then becomes what to do from there? Is their
some method to solve dependencies? How should we proceed to debug a
package installation? How do gurus deal with that? (maybe some less known
command line arguments? Or ways to figure out the problem and work out its
solution (cabal-install is silent in such case)? In particular, how to know
why did cabal get stuck in the first place?

- Some packages on Hackage are reported as not building successfully with
GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
and the later might depend on the former...What is one supposed to do in
such case? For example, is it an appropriate way to proceed to compile a
package with one version of GHC and then use the compiled package with
another version of GHC? Is it safe? What could possibly go wrong? If it is
the right way to go, how should we setup the two GHC versions? For instance,
should we have a shared package configuration file and choose through the
path which GHC is used or is there nicer way to set this up?
 
- Taking for example the encoding package on Hackage. Last time I tried,
the log was saying it fails to build on GHC 6.10, however, looking inside
this Hackage log, I could see a successful compilation using preferred
versions. So it looks as if the thing can be compiled somehow. What should
one do with this information? If cabal manages to compile it using this
method on Hackage, then isn't cabal install just doing it on my disk? Is it
possible through some command line? Is it possible manually (without
cabal-install) and, if so, how? (I tried to copy-past the build instruction
as it appeared on the log...that somehow compiled, but then, I failed to
figure out how to install...) 
  
- Im primarily a windows user and lots of my initial struggles probably
came from that. After many difficulties, I figured out that installing MinGW
and MSys was *THE* way to get a bit more of the things working. First, a lot
of time would be saved by just saying clearly on the GHC download page that
MinGW and MSys are mandatory installation (or even package that with GHC for
the windows distribution if license allows, who cares the extra few Mb).
Even if that is not technically exact, i.e., even if ghci and many trivial
command line programs can work without, MSys and MinGW turn out to be quiet
necessary whenever trying to install anything producing side effect. Making
it plain that these two are necessary would real come has a great time
savers for newbie like me on windows (personal opinion of course). Or, if
another path exists to go without these two, I'd be very glad to learn.
Besides, even these tools basic installation is not enough, you need
automake and various things of the like. That makes me wonder if the most
precious skill for programming with Haskell would not be a strong C/C++
programming background. 
 
- In face of the difficulties with windows, I switched to Linux. While some
things worked better, there were still lots of difficulties with package
compilation. For instance, it is very difficult to figure out which Linux
packages of a given distribution are needed for compiling this or that
package. Again, gtk2hs is epitome here: which C development packages are
needed to compile it is obscure at best (cairo, codeview, etc...). I ended
up querying the Debian package management with

Re: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Jonathan Cast

On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto
wrote:
 
 Last night I was thinking on what makes monads so hard to take, and
 came to a conclusion: the lack of a guided tour on the implemented
 monads.

...

 Inspired by the paper Functional Programming with Overloading and
 Higher-Order Polymorphism,
 Mark P Jones
 (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
   Advanced School of Functional Programming, 1995.
 
 SO WHAT?

So have you read Jones' paper?  Or do you have a *concrete* explanation
of how it differs from your desired `guided tour'?

jcc


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

[Haskell-cafe] Real World Haskell: confusion

On page 102: partial function application is named currying



I thought currying or to curry means converting



f :: (a,b) -c



into



g :: a - b - c



by applying curry (mmm, are Asian people good at Haskell? :-)

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

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread Eugene Kirpichov

The term 'currying' means both of these things:
 - Converting an uncurried function to a 'curriable' one
 - Partially applying a 'curriable' function

2009/1/13 Peter Verswyvelen bugf...@gmail.com:
 On page 102: partial function application is named currying



 I thought currying or to curry means converting



 f :: (a,b) -c



 into



 g :: a - b - c



 by applying curry (mmm, are Asian people good at Haskell? :-)


 g = curry f








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


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

[Haskell-cafe] Re: The problem with Monads...

2009-01-13 Thread Ertugrul Soeylemez

Jonathan Cast jonathancc...@fastmail.fm wrote:

 On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto
 wrote:

  Inspired by the paper Functional Programming with Overloading and
  Higher-Order Polymorphism,
  Mark P Jones
  (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
Advanced School of Functional Programming, 1995.
 
  SO WHAT?

 So have you read Jones' paper?  Or do you have a *concrete*
 explanation of how it differs from your desired `guided tour'?

I agree with Rafael here.  The standard library documentation is
insufficient.  Pointing to nothing else than a paper is about the same
as RTFM, especially being inspired by a paper, there is really
almost no information in the documentation.  I wouldn't expect from an
average programmer to read a whole paper to understand an everyday-use
monad.  Especially for newcomers to the purely functional world, even
reading the introduction of a paper may well take an hour, which can be
tiring and frustrating.

There should be some basic information about the monad at least at the
end of the documentation, as well as some well-thought usage examples.


Greets,
Ertugrul.


-- 
nightmare = unsafePerformIO (getWrongWife = sex)
http://blog.ertes.de/


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

Re: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Rafael Gustavo da Cunha Pereira Pinto

Yes, I've read it twice, and it is a nice explanation that yes, the reader
monad is an application and is a monad. How do I use it? Why not the
function itself? How would the plumbing work in a real world example?

BTW, the article is really great as an brief introduction to monad
transformers. For the whole concept of monads, my all time favorite is The
Haskell Programmer's Guide to the IO Monad by Stefan Klinger.

Chapters 14 to 19 of Real World Haskell also have a good introduction on
the usage of the monads, but it lacks other monads, like the RWS or the
Continuation...

See, that is my point. The mathematical concept of monads is very palatable.
The idea that monads are either patterns or structures to hide computations
in sequence is also very easy to see. But how do we use them?
Why should I use a Writer monad when I can use a (a,w) tuple?

On Tue, Jan 13, 2009 at 13:51, Jonathan Cast jonathancc...@fastmail.fmwrote:

On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto
wrote:

Last night I was thinking on what makes monads so hard to take, and
came to a conclusion: the lack of a guided tour on the implemented
monads.

...

Inspired by the paper Functional Programming with Overloading and
Higher-Order Polymorphism,
Mark P Jones
(http://web.cecs.pdx.edu/~mpj/pubs/springschool.htmlhttp://web.cecs.pdx.edu/%7Empj/pubs/springschool.html
)
Advanced School of Functional Programming, 1995.

SO WHAT?

So have you read Jones' paper? Or do you have a *concrete* explanation
of how it differs from your desired `guided tour'?

jcc

--
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Real World Haskell: confusion

Ah. That explains my confusion. But isn't that ambiguous terminology? There
must be some reason for it to be that way?
On Tue, Jan 13, 2009 at 5:05 PM, Eugene Kirpichov ekirpic...@gmail.comwrote:

 The term 'currying' means both of these things:
  - Converting an uncurried function to a 'curriable' one
  - Partially applying a 'curriable' function

 2009/1/13 Peter Verswyvelen bugf...@gmail.com:
  On page 102: partial function application is named currying
 
 
 
  I thought currying or to curry means converting
 
 
 
  f :: (a,b) -c
 
 
 
  into
 
 
 
  g :: a - b - c
 
 
 
  by applying curry (mmm, are Asian people good at Haskell? :-)
 
 
  g = curry f
 
 
 
 
 
 
 
 
  ___
  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] real haskell difficulties (at least for me)

2009-01-13 Thread Jamie Brandon

I agree completely. There is not nearly enough documentation on
packaging in haskell and too many hackage packages are broken or do
not install. I know several people are working on improving this but
they seem do be doing so rather quietly. Could someone briefly outline
what improvements are planned and what stage the current work is at? I
remember seeing some demos at anglohaskell during the summer but
nothing since.

Jamie

On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul
regis.saint-p...@create-net.org wrote:
 Hi,

 I've seen many times the monad topic coming around on the cafe and plentiful
 tutorials on monads have been published. However, as a complete Haskell
 newbie coming from OOP, I felt monads were not particularly difficult to
 grasp, and very exciting to work with.

 During my experiments with Haskell so far, the main problems I kept bumping
 into were not related to the language but to its libraries: their
 compilation and installation. Unfortunately, this topic has not received
 nearly as much attention. I was unable to find a comprehensive tutorial on
 how to deal with the variety of problems I get when trying to install
 Hackage packages. This turned out to be (and still is) THE main source of
 wasted time and headaches. And worse, unlike type problems, these are not
 interesting ones to solve.

 Thus, as a beginner, the package management is what is really getting in the
 way of switching to Haskell--not the language. Even books like Real World
 Haskell (otherwise excellent) ignore entirely the topic. Cabal and
 Cabal-install are clearly wonderful applications that make installing most
 packages very straightforward. Unfortunately, whenever this standard
 method for package installation fails (or when it is not available as with,
 e.g., gtk2hs), I find myself in complete disarray.

 Below are some of the questions and issues I faced regarding package
 management:

 - For a number of packages, cabal-install gets stuck and has to be killed. I
 assume this is due to some difficulties in solving the dependencies and it
 is fine, not all can be automated and cabal-install is not responsible for
 poor packages. But the question then becomes what to do from there? Is their
 some method to solve dependencies? How should we proceed to debug a
 package installation? How do gurus deal with that? (maybe some less known
 command line arguments? Or ways to figure out the problem and work out its
 solution (cabal-install is silent in such case)? In particular, how to know
 why did cabal get stuck in the first place?

 - Some packages on Hackage are reported as not building successfully with
 GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
 and the later might depend on the former...What is one supposed to do in
 such case? For example, is it an appropriate way to proceed to compile a
 package with one version of GHC and then use the compiled package with
 another version of GHC? Is it safe? What could possibly go wrong? If it is
 the right way to go, how should we setup the two GHC versions? For instance,
 should we have a shared package configuration file and choose through the
 path which GHC is used or is there nicer way to set this up?

 - Taking for example the encoding package on Hackage. Last time I tried,
 the log was saying it fails to build on GHC 6.10, however, looking inside
 this Hackage log, I could see a successful compilation using preferred
 versions. So it looks as if the thing can be compiled somehow. What should
 one do with this information? If cabal manages to compile it using this
 method on Hackage, then isn't cabal install just doing it on my disk? Is it
 possible through some command line? Is it possible manually (without
 cabal-install) and, if so, how? (I tried to copy-past the build instruction
 as it appeared on the log...that somehow compiled, but then, I failed to
 figure out how to install...)

 - I'm primarily a windows user and lots of my initial struggles probably
 came from that. After many difficulties, I figured out that installing MinGW
 and MSys was *THE* way to get a bit more of the things working. First, a lot
 of time would be saved by just saying clearly on the GHC download page that
 MinGW and MSys are mandatory installation (or even package that with GHC for
 the windows distribution if license allows, who cares the extra few Mb).
 Even if that is not technically exact, i.e., even if ghci and many trivial
 command line programs can work without, MSys and MinGW turn out to be quiet
 necessary whenever trying to install anything producing side effect. Making
 it plain that these two are necessary would real come has a great time
 savers for newbie like me on windows (personal opinion of course). Or, if
 another path exists to go without these two, I'd be very glad to learn.
 Besides, even these tools basic installation is not enough, you need
 automake and various things of the like. That makes me wonder if the most
 precious

RE: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Sittampalam, Ganesh

Jonathan Cast wrote:
 On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira
 Pinto wrote:

 Inspired by the paper Functional Programming with Overloading and
 Higher-Order Polymorphism, Mark P Jones
 (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
   Advanced School of Functional Programming, 1995.
 
 SO WHAT?
 
 So have you read Jones' paper?  Or do you have a *concrete*
 explanation of how it differs from your desired `guided tour'? 

To give a specific example, a few weeks ago I wanted an explanation of
the 'pass' function and couldn't find it in that paper.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

2009-01-13 Thread Krzysztof Skrzętnicki

My experience from using GHC under Windows XP is very similar. Many
packages (especially those involving bindings to C packages) are at
least painful to build.
Regarding encoding package: it compiles fine for me:

C:\Documents and Settings\Methariuscabal install encoding
Resolving dependencies...
Downloading encoding-0.4.1...
Configuring encoding-0.4.1...
Preprocessing library encoding-0.4.1...
Building encoding-0.4.1...
[ 1 of 37] Compiling Data.Encoding.Helper.Template (
Data\Encoding\Helper\Template.hs,
dist\build\Data\Encoding\Helper\Template.o )
[ 2 of 37] Compiling Data.Encoding.GB18030Data (
Data\Encoding\GB18030Data.hs, dist\build\Data\Encoding\GB18030Data.o )
[ 3 of 37] Compiling Data.Encoding.Base ( Data\Encoding\Base.hs,
dist\build\Data\Encoding\Base.o )
[ 4 of 37] Compiling Data.Encoding.GB18030 ( Data\Encoding\GB18030.hs,
dist\build\Data\Encoding\GB18030.o )
[ 5 of 37] Compiling Data.Encoding.KOI8U ( Data\Encoding\KOI8U.hs,
dist\build\Data\Encoding\KOI8U.o )
[ 6 of 37] Compiling Data.Encoding.KOI8R ( Data\Encoding\KOI8R.hs,
dist\build\Data\Encoding\KOI8R.o )
[ 7 of 37] Compiling Data.Encoding.CP1258 ( Data\Encoding\CP1258.hs,
dist\build\Data\Encoding\CP1258.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.0 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package regex-base-0.72.0.2 ... linking ... done.
Loading package regex-posix-0.72.0.3 ... linking ... done.
Loading package regex-compat-0.71.0.1 ... linking ... done.
Loading package base-3.0.3.0 ... linking ... done.
[ 8 of 37] Compiling Data.Encoding.CP1257 ( Data\Encoding\CP1257.hs,
dist\build\Data\Encoding\CP1257.o )
[ 9 of 37] Compiling Data.Encoding.CP1256 ( Data\Encoding\CP1256.hs,
dist\build\Data\Encoding\CP1256.o )
[10 of 37] Compiling Data.Encoding.CP1255 ( Data\Encoding\CP1255.hs,
dist\build\Data\Encoding\CP1255.o )
[11 of 37] Compiling Data.Encoding.CP1254 ( Data\Encoding\CP1254.hs,
dist\build\Data\Encoding\CP1254.o )
[12 of 37] Compiling Data.Encoding.CP1253 ( Data\Encoding\CP1253.hs,
dist\build\Data\Encoding\CP1253.o )
[13 of 37] Compiling Data.Encoding.CP1252 ( Data\Encoding\CP1252.hs,
dist\build\Data\Encoding\CP1252.o )
[14 of 37] Compiling Data.Encoding.CP1251 ( Data\Encoding\CP1251.hs,
dist\build\Data\Encoding\CP1251.o )
[15 of 37] Compiling Data.Encoding.CP1250 ( Data\Encoding\CP1250.hs,
dist\build\Data\Encoding\CP1250.o )
[16 of 37] Compiling Data.Encoding.BootString (
Data\Encoding\BootString.hs, dist\build\Data\Encoding\BootString.o )
[17 of 37] Compiling Data.Encoding.ISO885916 (
Data\Encoding\ISO885916.hs, dist\build\Data\Encoding\ISO885916.o )
[18 of 37] Compiling Data.Encoding.ISO885915 (
Data\Encoding\ISO885915.hs, dist\build\Data\Encoding\ISO885915.o )
[19 of 37] Compiling Data.Encoding.ISO885914 (
Data\Encoding\ISO885914.hs, dist\build\Data\Encoding\ISO885914.o )
[20 of 37] Compiling Data.Encoding.ISO885913 (
Data\Encoding\ISO885913.hs, dist\build\Data\Encoding\ISO885913.o )
[21 of 37] Compiling Data.Encoding.ISO885911 (
Data\Encoding\ISO885911.hs, dist\build\Data\Encoding\ISO885911.o )
[22 of 37] Compiling Data.Encoding.ISO885910 (
Data\Encoding\ISO885910.hs, dist\build\Data\Encoding\ISO885910.o )
[23 of 37] Compiling Data.Encoding.ISO88599 (
Data\Encoding\ISO88599.hs, dist\build\Data\Encoding\ISO88599.o )
[24 of 37] Compiling Data.Encoding.ISO88598 (
Data\Encoding\ISO88598.hs, dist\build\Data\Encoding\ISO88598.o )
[25 of 37] Compiling Data.Encoding.ISO88597 (
Data\Encoding\ISO88597.hs, dist\build\Data\Encoding\ISO88597.o )
[26 of 37] Compiling Data.Encoding.ISO88596 (
Data\Encoding\ISO88596.hs, dist\build\Data\Encoding\ISO88596.o )
[27 of 37] Compiling Data.Encoding.ISO88595 (
Data\Encoding\ISO88595.hs, dist\build\Data\Encoding\ISO88595.o )
[28 of 37] Compiling Data.Encoding.ISO88594 (
Data\Encoding\ISO88594.hs, dist\build\Data\Encoding\ISO88594.o )
[29 of 37] Compiling Data.Encoding.ISO88593 (
Data\Encoding\ISO88593.hs, dist\build\Data\Encoding\ISO88593.o )
[30 of 37] Compiling Data.Encoding.ISO88592 (
Data\Encoding\ISO88592.hs, dist\build\Data\Encoding\ISO88592.o )
[31 of 37] Compiling Data.Encoding.ISO88591 (
Data\Encoding\ISO88591.hs, dist\build\Data\Encoding\ISO88591.o )
[32 of 37] Compiling Data.Encoding.UTF32 ( Data\Encoding\UTF32.hs,
dist\build\Data\Encoding\UTF32.o )
[33 of 37] Compiling Data.Encoding.UTF16 ( Data\Encoding\UTF16.hs,
dist\build\Data\Encoding\UTF16.o )
[34 of 37] Compiling Data.Encoding.UTF8 ( Data\Encoding\UTF8.hs,
dist\build\Data\Encoding\UTF8.o )
[35 of 37] Compiling Data.Encoding.ASCII ( Data\Encoding\ASCII.hs,
dist\build\Data\Encoding\ASCII.o )
[36 of 37] Compiling

Re: [Haskell-cafe] real haskell difficulties (at least for me)


Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.

Regarding libraries in general, the platform project is underway, aiming
to bless a set of stable, batteries included packages, saving
duplicated work determining which, say, json library to use.

-- Don


jamiiecb:
 I agree completely. There is not nearly enough documentation on
 packaging in haskell and too many hackage packages are broken or do
 not install. I know several people are working on improving this but
 they seem do be doing so rather quietly. Could someone briefly outline
 what improvements are planned and what stage the current work is at? I
 remember seeing some demos at anglohaskell during the summer but
 nothing since.
 
 Jamie
 
 On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul
 regis.saint-p...@create-net.org wrote:
  Hi,
 
  I've seen many times the monad topic coming around on the cafe and plentiful
  tutorials on monads have been published. However, as a complete Haskell
  newbie coming from OOP, I felt monads were not particularly difficult to
  grasp, and very exciting to work with.
 
  During my experiments with Haskell so far, the main problems I kept bumping
  into were not related to the language but to its libraries: their
  compilation and installation. Unfortunately, this topic has not received
  nearly as much attention. I was unable to find a comprehensive tutorial on
  how to deal with the variety of problems I get when trying to install
  Hackage packages. This turned out to be (and still is) THE main source of
  wasted time and headaches. And worse, unlike type problems, these are not
  interesting ones to solve.
 
  Thus, as a beginner, the package management is what is really getting in the
  way of switching to Haskell--not the language. Even books like Real World
  Haskell (otherwise excellent) ignore entirely the topic. Cabal and
  Cabal-install are clearly wonderful applications that make installing most
  packages very straightforward. Unfortunately, whenever this standard
  method for package installation fails (or when it is not available as with,
  e.g., gtk2hs), I find myself in complete disarray.
 
  Below are some of the questions and issues I faced regarding package
  management:
 
  - For a number of packages, cabal-install gets stuck and has to be killed. I
  assume this is due to some difficulties in solving the dependencies and it
  is fine, not all can be automated and cabal-install is not responsible for
  poor packages. But the question then becomes what to do from there? Is their
  some method to solve dependencies? How should we proceed to debug a
  package installation? How do gurus deal with that? (maybe some less known
  command line arguments? Or ways to figure out the problem and work out its
  solution (cabal-install is silent in such case)? In particular, how to know
  why did cabal get stuck in the first place?
 
  - Some packages on Hackage are reported as not building successfully with
  GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
  and the later might depend on the former...What is one supposed to do in
  such case? For example, is it an appropriate way to proceed to compile a
  package with one version of GHC and then use the compiled package with
  another version of GHC? Is it safe? What could possibly go wrong? If it is
  the right way to go, how should we setup the two GHC versions? For instance,
  should we have a shared package configuration file and choose through the
  path which GHC is used or is there nicer way to set this up?
 
  - Taking for example the encoding package on Hackage. Last time I tried,
  the log was saying it fails to build on GHC 6.10, however, looking inside
  this Hackage log, I could see a successful compilation using preferred
  versions. So it looks as if the thing can be compiled somehow. What should
  one do with this information? If cabal manages to compile it using this
  method on Hackage, then isn't cabal install just doing it on my disk? Is it
  possible through some command line? Is it possible manually (without
  cabal-install) and, if so, how? (I tried to copy-past the build instruction
  as it appeared on the log...that somehow compiled, but then, I failed to
  figure out how to install...)
 
  - I'm primarily a windows user and lots of my initial struggles probably
  came from that. After many difficulties, I figured out that installing MinGW
  and MSys was *THE* way to get a bit more of the things working. First, a lot
  of time would be saved by just saying clearly on the GHC download page that
  MinGW and MSys are mandatory installation (or even package that with GHC for
  the windows distribution if license allows, who cares the extra few Mb).
  Even if that is not technically exact, i.e., even if ghci and many trivial
  command line programs can work without, MSys and MinGW turn out to be quiet
  necessary whenever trying to install

RE: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Derek Elkins

On Tue, 2009-01-13 at 16:22 +, Sittampalam, Ganesh wrote:
 Jonathan Cast wrote:
  On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira
  Pinto wrote:
 
  Inspired by the paper Functional Programming with Overloading and
  Higher-Order Polymorphism, Mark P Jones
  (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
Advanced School of Functional Programming, 1995.
  
  SO WHAT?
  
  So have you read Jones' paper?  Or do you have a *concrete*
  explanation of how it differs from your desired `guided tour'? 
 
 To give a specific example, a few weeks ago I wanted an explanation of
 the 'pass' function and couldn't find it in that paper.
 
 Ganesh

Several years ago I documented all the (basic) monads in the mtl on the
(old) wiki.
http://web.archive.org/web/20030927210146/haskell.org/hawiki/MonadTemplateLibrary
In particular,
http://web.archive.org/web/20030907203223/haskell.org/hawiki/MonadWriter


To respond to the essential point of Rafael's initial claim, Wadler's
papers The Essence of Functional Programming and/or Monads for
Functional Programming have exactly what he wants.  These are the
papers that I recommend to anyone who is learning about monads.
http://homepages.inf.ed.ac.uk/wadler/topics/monads.html

Please, we do not need the 101st monad tutorial when there was an
adequate one made almost two decades ago.  While I'm not saying that
this is the case here, I suspect that many people don't read those
papers because 1) they haven't heard of them and 2) they are papers
and thus couldn't possibly be readable and understandable (which also
partially causes (1) as people just don't think to look for papers at
all.)

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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

What could be done is letting the community rate the quality of the modules
for each platform? Maybe with user comments? Like amazon.com (so we
hackazon.org ;-)  And using lambdas instead of stars for giving the rating
:)

On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart d...@galois.com wrote:


 Well, the number one thing is to use Cabal and the cabal-install tool.
 That is the simplest way to avoid headaches.

 Regarding libraries in general, the platform project is underway, aiming
 to bless a set of stable, batteries included packages, saving
 duplicated work determining which, say, json library to use.

 -- Don


 jamiiecb:
  I agree completely. There is not nearly enough documentation on
  packaging in haskell and too many hackage packages are broken or do
  not install. I know several people are working on improving this but
  they seem do be doing so rather quietly. Could someone briefly outline
  what improvements are planned and what stage the current work is at? I
  remember seeing some demos at anglohaskell during the summer but
  nothing since.
 
  Jamie
 
  On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul
  regis.saint-p...@create-net.org wrote:
   Hi,
  
   I've seen many times the monad topic coming around on the cafe and
 plentiful
   tutorials on monads have been published. However, as a complete Haskell
   newbie coming from OOP, I felt monads were not particularly difficult
 to
   grasp, and very exciting to work with.
  
   During my experiments with Haskell so far, the main problems I kept
 bumping
   into were not related to the language but to its libraries: their
   compilation and installation. Unfortunately, this topic has not
 received
   nearly as much attention. I was unable to find a comprehensive tutorial
 on
   how to deal with the variety of problems I get when trying to install
   Hackage packages. This turned out to be (and still is) THE main source
 of
   wasted time and headaches. And worse, unlike type problems, these are
 not
   interesting ones to solve.
  
   Thus, as a beginner, the package management is what is really getting
 in the
   way of switching to Haskell--not the language. Even books like Real
 World
   Haskell (otherwise excellent) ignore entirely the topic. Cabal and
   Cabal-install are clearly wonderful applications that make installing
 most
   packages very straightforward. Unfortunately, whenever this standard
   method for package installation fails (or when it is not available as
 with,
   e.g., gtk2hs), I find myself in complete disarray.
  
   Below are some of the questions and issues I faced regarding package
   management:
  
   - For a number of packages, cabal-install gets stuck and has to be
 killed. I
   assume this is due to some difficulties in solving the dependencies and
 it
   is fine, not all can be automated and cabal-install is not responsible
 for
   poor packages. But the question then becomes what to do from there? Is
 their
   some method to solve dependencies? How should we proceed to debug a
   package installation? How do gurus deal with that? (maybe some less
 known
   command line arguments? Or ways to figure out the problem and work out
 its
   solution (cabal-install is silent in such case)? In particular, how to
 know
   why did cabal get stuck in the first place?
  
   - Some packages on Hackage are reported as not building successfully
 with
   GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g.,
 salvia)
   and the later might depend on the former...What is one supposed to do
 in
   such case? For example, is it an appropriate way to proceed to compile
 a
   package with one version of GHC and then use the compiled package with
   another version of GHC? Is it safe? What could possibly go wrong? If it
 is
   the right way to go, how should we setup the two GHC versions? For
 instance,
   should we have a shared package configuration file and choose through
 the
   path which GHC is used or is there nicer way to set this up?
  
   - Taking for example the encoding package on Hackage. Last time I
 tried,
   the log was saying it fails to build on GHC 6.10, however, looking
 inside
   this Hackage log, I could see a successful compilation using preferred
   versions. So it looks as if the thing can be compiled somehow. What
 should
   one do with this information? If cabal manages to compile it using this
   method on Hackage, then isn't cabal install just doing it on my disk?
 Is it
   possible through some command line? Is it possible manually (without
   cabal-install) and, if so, how? (I tried to copy-past the build
 instruction
   as it appeared on the log...that somehow compiled, but then, I failed
 to
   figure out how to install...)
  
   - I'm primarily a windows user and lots of my initial struggles
 probably
   came from that. After many difficulties, I figured out that installing
 MinGW
   and MSys was *THE* way to get a bit more of the things working. First,
 a lot
   of time would be saved

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread Dan Piponi

2009/1/13 Peter Verswyvelen bugf...@gmail.com:
 On page 102: partial function application is named currying
 I thought currying or to curry means converting
 f :: (a,b) -c

Confusion over these terms is commonplace. See, for example, the
discussion here: http://lambda-the-ultimate.org/node/2266
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: real haskell difficulties (at least for me)

2009-01-13 Thread Mauricio



There's a 'stability' field on cabal description files. Maybe
it could appear after the name on the main listing. Or, all
packages marked as 'Stable' at that field could get a beautifull
color.


I agree completely. There is not nearly enough documentation on
packaging in haskell and too many hackage packages are broken or do
not install. I know several people are working on improving this but
they seem do be doing so rather quietly. Could someone briefly outline
what improvements are planned and what stage the current work is at? I
remember seeing some demos at anglohaskell during the summer but
nothing since.

Jamie

On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul
regis.saint-p...@create-net.org wrote:

Hi,

I've seen many times the monad topic coming around on the cafe and plentiful
tutorials on monads have been published. However, as a complete Haskell
newbie coming from OOP, I felt monads were not particularly difficult to
grasp, and very exciting to work with.

During my experiments with Haskell so far, the main problems I kept bumping
into were not related to the language but to its libraries: their
compilation and installation. Unfortunately, this topic has not received
nearly as much attention. I was unable to find a comprehensive tutorial on
how to deal with the variety of problems I get when trying to install
Hackage packages. This turned out to be (and still is) THE main source of
wasted time and headaches. And worse, unlike type problems, these are not
interesting ones to solve.

Thus, as a beginner, the package management is what is really getting in the
way of switching to Haskell--not the language. Even books like Real World
Haskell (otherwise excellent) ignore entirely the topic. Cabal and
Cabal-install are clearly wonderful applications that make installing most
packages very straightforward. Unfortunately, whenever this standard
method for package installation fails (or when it is not available as with,
e.g., gtk2hs), I find myself in complete disarray.

Below are some of the questions and issues I faced regarding package
management:

- For a number of packages, cabal-install gets stuck and has to be killed. I
assume this is due to some difficulties in solving the dependencies and it
is fine, not all can be automated and cabal-install is not responsible for
poor packages. But the question then becomes what to do from there? Is their
some method to solve dependencies? How should we proceed to debug a
package installation? How do gurus deal with that? (maybe some less known
command line arguments? Or ways to figure out the problem and work out its
solution (cabal-install is silent in such case)? In particular, how to know
why did cabal get stuck in the first place?

- Some packages on Hackage are reported as not building successfully with
GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
and the later might depend on the former...What is one supposed to do in
such case? For example, is it an appropriate way to proceed to compile a
package with one version of GHC and then use the compiled package with
another version of GHC? Is it safe? What could possibly go wrong? If it is
the right way to go, how should we setup the two GHC versions? For instance,
should we have a shared package configuration file and choose through the
path which GHC is used or is there nicer way to set this up?

- Taking for example the encoding package on Hackage. Last time I tried,
the log was saying it fails to build on GHC 6.10, however, looking inside
this Hackage log, I could see a successful compilation using preferred
versions. So it looks as if the thing can be compiled somehow. What should
one do with this information? If cabal manages to compile it using this
method on Hackage, then isn't cabal install just doing it on my disk? Is it
possible through some command line? Is it possible manually (without
cabal-install) and, if so, how? (I tried to copy-past the build instruction
as it appeared on the log...that somehow compiled, but then, I failed to
figure out how to install...)

- I'm primarily a windows user and lots of my initial struggles probably
came from that. After many difficulties, I figured out that installing MinGW
and MSys was *THE* way to get a bit more of the things working. First, a lot
of time would be saved by just saying clearly on the GHC download page that
MinGW and MSys are mandatory installation (or even package that with GHC for
the windows distribution if license allows, who cares the extra few Mb).
Even if that is not technically exact, i.e., even if ghci and many trivial
command line programs can work without, MSys and MinGW turn out to be quiet
necessary whenever trying to install anything producing side effect. Making
it plain that these two are necessary would real come has a great time
savers for newbie like me on windows (personal opinion of course). Or, if
another path exists to go without these two, I'd be very glad to learn.
Besides, even these

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

2009-01-13 Thread Andrew Coppin


Robin Green wrote:

On Mon, 12 Jan 2009 21:04:35 +0100 (CET)
Henning Thielemann lemm...@henning-thielemann.de wrote:

  

On Mon, 12 Jan 2009, Andrew Coppin wrote:



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 (n0) (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)


One of the wonderful things about Haskell is that almost any time 
anybody posts code, at least one person will think up an alternative but 
equivilent way of achieving the same goal - sometimes by radically 
different steps.


Maybe we should have a name for this effect?

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

2009-01-13 Thread Tim Newsham


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.


Maybe that was the initial reason, but I've actually found the
Binary.Put.PutM (where Put = PutM ()) to be useful.  Sometimes
your putter does need to propogate a result...

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: databases in Haskell type-safety

 John == John Goerzen jgoer...@complete.org writes:

John That's great.  Even better if accompanied by a patch ;-)

Heh, one of the things which prevents me advancing with my own Haskell
project is lack of enough skills to provide bindings for one C-lib and
here I see the same pattern...It looks I have to cross it over :-)

 I'll e.g. open ticket for BLOB support :-D

John Of course :-)

I did it - have you seen the notice about problems with HDBC-forums?

John Yes, I'm quite aware of that.  Just not *my* particular ones ;-)

OK. I'll try to, at least, come with some concrete proposal...


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D



pgp4XCOSKVTcP.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: databases in Haskell type-safety

 Mauricio == Mauricio  briqueabra...@yahoo.com writes:

Mauricio I've been doing a lot of low level sqlite3 lately (it's going
Mauricio to be on a hackage package as soon as I finish my current
Mauricio work). 

Have you done any work with BLOBs?

Mauricio As long as I clearly isolate and test the marshalling of my
Mauricio data to SQL and back, my (personal, probably different from
Mauricio yours) experience using just sqlite3_exec has never got me
Mauricio into trouble.

Thank you for your input.


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D



pgp1VtGIKB8bM.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Rafael Gustavo da Cunha Pereira Pinto

I didn't knew Wadler's papers (I save all papers I read into a external USB
HD, so I can read them later!), and at a first glance it is really good.


Then again, instead of creating another monad tutorial, what about a
Haskell monads reference guide, and some worked examples?

Some of this work could even be attached to the library documentation.

Regards

Rafael


On Tue, Jan 13, 2009 at 15:27, Derek Elkins derek.a.elk...@gmail.comwrote:

 On Tue, 2009-01-13 at 16:22 +, Sittampalam, Ganesh wrote:
  Jonathan Cast wrote:
   On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira
   Pinto wrote:
  
   Inspired by the paper Functional Programming with Overloading and
   Higher-Order Polymorphism, Mark P Jones
   (http://web.cecs.pdx.edu/~mpj/pubs/springschool.htmlhttp://web.cecs.pdx.edu/%7Empj/pubs/springschool.html
 )
 Advanced School of Functional Programming, 1995.
  
   SO WHAT?
  
   So have you read Jones' paper?  Or do you have a *concrete*
   explanation of how it differs from your desired `guided tour'?
 
  To give a specific example, a few weeks ago I wanted an explanation of
  the 'pass' function and couldn't find it in that paper.
 
  Ganesh

 Several years ago I documented all the (basic) monads in the mtl on the
 (old) wiki.

 http://web.archive.org/web/20030927210146/haskell.org/hawiki/MonadTemplateLibrary
 In particular,
 http://web.archive.org/web/20030907203223/haskell.org/hawiki/MonadWriter


 To respond to the essential point of Rafael's initial claim, Wadler's
 papers The Essence of Functional Programming and/or Monads for
 Functional Programming have exactly what he wants.  These are the
 papers that I recommend to anyone who is learning about monads.
 http://homepages.inf.ed.ac.uk/wadler/topics/monads.html

 Please, we do not need the 101st monad tutorial when there was an
 adequate one made almost two decades ago.  While I'm not saying that
 this is the case here, I suspect that many people don't read those
 papers because 1) they haven't heard of them and 2) they are papers
 and thus couldn't possibly be readable and understandable (which also
 partially causes (1) as people just don't think to look for papers at
 all.)




-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: databases in Haskell type-safety

Gour wrote:
 John == John Goerzen jgoer...@complete.org writes:
 
 John That's great.  Even better if accompanied by a patch ;-)
 
 Heh, one of the things which prevents me advancing with my own Haskell
 project is lack of enough skills to provide bindings for one C-lib and
 here I see the same pattern...It looks I have to cross it over :-)
 
 I'll e.g. open ticket for BLOB support :-D
 
 John Of course :-)
 
 I did it - have you seen the notice about problems with HDBC-forums?

Yes.  I am thoroughly displeased with Ruby on Rails at the moment.  It
is less maintainable than a network of DOS boxes.  There are a host of
mysterious crashes in Redmine at the moment -- including one where
pulling up the page for one specific bug (but none others) crashes the
server.

I could upgrade Redmine, but that requires a Ruby stack that is partly
newer than what's in Debian, and the upgrade for that process appears to
succeed, but then fails in mysterious ways at the end.

To anyone annoyed with Haskell's library install process: you have no
idea how good you have it unless you've tried Ruby and rails.

-- John

___
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


Judah Jacobson ha scritto:

[...]


(For those interested: rlwrap is available in cygwin.
It used to work very well on old ghci, when line
editing wasn't available.)


This does sound useful; the main difficulty is that when a program has
stdin piped from another process it may behaved differently.  For
example, ghci uses block buffering and doesn't print its prompt when
stdin doesn't appear to be a terminal.  The solution on POSIX is
probably to use some sort of pseudo-terminal support; I don't know
what the right thing to do on Windows is.



On Windows you can create a Console object:
http://msdn.microsoft.com/en-us/library/ms682087.aspx


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

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

2009-01-13 Thread Colin Adams

2009/1/13 Andrew Coppin andrewcop...@btinternet.com:

 One of the wonderful things about Haskell is that almost any time anybody
 posts code, at least one person will think up an alternative but equivilent
 way of achieving the same goal - sometimes by radically different steps.

 Maybe we should have a name for this effect?

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

[Haskell-cafe] Re: Arch Haskell News: Jan 11 2009

2009-01-13 Thread Peter Hercek


Hi,

Any idea why ghc 6.10.1 is still in Testing repository on archlinux?

Peter.

Don Stewart wrote:

Arch Haskell News: Jan 11 2009

--cut--

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

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

Colin Adams wrote:
 2009/1/13 Andrew Coppin andrewcop...@btinternet.com:
 
 One of the wonderful things about Haskell is that almost any time anybody
 posts code, at least one person will think up an alternative but equivilent
 way of achieving the same goal - sometimes by radically different steps.

 Maybe we should have a name for this effect?
 
 Confusion.

Ah, so Haskell is completely reducible to Perl then? ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: json-0.4.1

2009-01-13 Thread Alex Ott

Hello

 SF == Sigbjorn Finne writes:
 SF Hi, a new release of the 'json' package is now available via hackage,
 SF version 0.4.1

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

I tried to upgrade it via cabal on mac os x  linux (both use ghc 6.10.1)
and it fails with

Building json-0.4.1...

Text/JSON/Generic.hs:33:7:
Could not find module `Data.Generics':
  it was found in multiple packages: base-3.0.3.0 syb
cabal: Error: some packages failed to install:
json-0.4.1 failed during the building phase. The exception was:
exit: ExitFailure 1

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/http://xtalk.msk.su/~ott/
http://alexott-ru.blogspot.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Adding Authentication and Authorization to a service implemented in Haskell

2009-01-13 Thread Daryoush Mehrtash

I am trying to figure out a clean way to add authentication and
authorization in a webservice.   The services of the web services are
implemented as Haskell functions.  The request to the service contains the
user authentication information.   I want to authenticate the user by
verifying his authentication informaton, assign him roles, and then based on
the roles decide on the functions and data that he can have access too.   Is
there a clean way to do this in Haskell?


Thanks

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

[Haskell-cafe] Re: databases in Haskell type-safety

2009-01-13 Thread Mauricio


Mauricio I've been doing a lot of low level sqlite3 lately (it's going
Mauricio to be on a hackage package as soon as I finish my current
Mauricio work). 


Have you done any work with BLOBs?



No. Only sqlite3_exec with INSERT, SELECT stuff,
and saving everything that needs structure in
pseudo-xml strings. Not that efficient, but easy
to change to blobs when everything is ready and
tested.

Maurício

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

Re: [Haskell-cafe] ANN: json-0.4.1

2009-01-13 Thread Bas van Dijk

On Tue, Jan 13, 2009 at 8:47 PM, Alex Ott alex...@gmail.com wrote:
 Hello

 SF == Sigbjorn Finne writes:
  SF Hi, a new release of the 'json' package is now available via hackage,
  SF version 0.4.1

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

 I tried to upgrade it via cabal on mac os x  linux (both use ghc 6.10.1)
 and it fails with

 Building json-0.4.1...

 Text/JSON/Generic.hs:33:7:
Could not find module `Data.Generics':
  it was found in multiple packages: base-3.0.3.0 syb
 cabal: Error: some packages failed to install:
 json-0.4.1 failed during the building phase. The exception was:
 exit: ExitFailure 1

The standard solution for this is to add a cabal flag that controls
wether to depend on base-4 or base-3:

--
flag small_base
  description:  Choose the new smaller, split-up base package.

Library
  if flag(small_base)
Build-Depends:  base == 4.*, syb
CPP-Options:-DBASE_4
  else
Build-Depends:  base == 3.*
--

And use some CPP in your modules like this:

--
{-# LANGUAGE CPP #-}

#ifdef BASE_4
import Data.Data (Data)
#else
import Data.Generics (Data)
#endif
--

See for example how I do it in http://code.haskell.org/Stream

regards,

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

[Haskell-cafe] Re: [ANN] Working with HLint from Emacs

 Alex == Alex Ott alex...@gmail.com writes:

Alex Hello For Emacs users it could be interesting - I wrote small
Alex module for more comfortable work with HLint from Emacs. It has
Alex same functionality as compilation-mode - navigation between
Alex errors, etc.

Thank you for it.

Alex Module is available from
Alex http://xtalk.msk.su/~ott/common/emacs/hs-lint.el

Module is not under some dvcs?


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D



pgpGGk0oAgZEP.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: databases in Haskell type-safety

 Johannes == Johannes Waldmann waldm...@imn.htwk-leipzig.de writes:

Johannes see
Johannes http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490

Thanks.

Is it just a 'fix' or HSQL will be properly maintained as well?


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D



pgpo8XJalZryl.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: databases in Haskell type-safety

 Mauricio == Mauricio  briqueabra...@yahoo.com writes:

Mauricio No. Only sqlite3_exec with INSERT, SELECT stuff,
Mauricio and saving everything that needs structure in pseudo-xml
Mauricio strings. Not that efficient, but easy to change to blobs when
Mauricio everything is ready and tested.

I see...I'm thinking to maybe store only paths for bigger BLOBs, but
still there is need to store smaller (thumbnails pics) ones...


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D



pgp4nqCuaRKrq.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] real haskell difficulties (at least for me)

2009-01-13 Thread Erik de Castro Lopo

Don Stewart wrote:

 Well, the number one thing is to use Cabal and the cabal-install tool.
 That is the simplest way to avoid headaches.

I'm sure cabal  works very  well for many people, but for anyone who
has used Debian based distributions for some time,  cabal really
does seem like a backward step.

For instance, I regularly develop on 6 machines; personal laptop,
home desktop, 2 work desktops and 2 work build machines.

At work, the main output of my development work is Debian packages
(which get installed on hundreds of machines), and the Debian packages
I create have build depends on whatever compilers and libraries are
required to build them. We also have a build bot that runs nightly
in a clean chroot for each package so that build depends can  be
verified to be correct.

However, if I install compilers or libraries using cabal there is
no package to build depend on, breaking a system which currently
works very, very  well for all the code we build in C, C++ and
Ocaml.

Erik
-- 
-
Erik de Castro Lopo
-
Arguing that Java is better than C++ is like arguing that
grasshoppers taste better than tree bark. -- Thant Tessman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

2009-01-13 Thread George Pollard

On Mon, 2009-01-12 at 21:48 +, Robin Green wrote:
   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 (n0) (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))

I have the equivalent in my ‘useful functions’:

 ifM p x = if p then return x else mzero




signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-beginners] Re: [Haskell-cafe] The problem with Monads...

2009-01-13 Thread Henk-Jan van Tuyl

On Tue, 13 Jan 2009 19:35:57 +0100, Rafael Gustavo da Cunha Pereira Pinto  
rafaelgcpp.li...@gmail.com wrote:


I didn't knew Wadler's papers (I save all papers I read into a external  
USB

HD, so I can read them later!), and at a first glance it is really good.


Then again, instead of creating another monad tutorial, what about a
Haskell monads reference guide, and some worked examples?

Some of this work could even be attached to the library documentation.

Regards

Rafael



I have written a reference manual for the basic Haskell monad functions,  
A Tour of the Haskell Monad functions. It contains a lot of examples.  
You can find it at:

  http://members.chello.nl/hjgtuyl/tourdemonad.html

As far as I know, there is no reference guide for advanced monads, like  
the Reader, Writer and State monads.


--
Regards,
Henk-Jan van Tuyl


--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--


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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

mle+cl:
 Don Stewart wrote:
 
  Well, the number one thing is to use Cabal and the cabal-install tool.
  That is the simplest way to avoid headaches.
 
 I'm sure cabal  works very  well for many people, but for anyone who
 has used Debian based distributions for some time,  cabal really
 does seem like a backward step.
 
 For instance, I regularly develop on 6 machines; personal laptop,
 home desktop, 2 work desktops and 2 work build machines.
 
 At work, the main output of my development work is Debian packages
 (which get installed on hundreds of machines), and the Debian packages
 I create have build depends on whatever compilers and libraries are
 required to build them. We also have a build bot that runs nightly
 in a clean chroot for each package so that build depends can  be
 verified to be correct.
 
 However, if I install compilers or libraries using cabal there is
 no package to build depend on, breaking a system which currently
 works very, very  well for all the code we build in C, C++ and
 Ocaml.

I encourage *strongly* the Debian community to package up hackage
packages natively, as we have done on Gentoo and Arch.

(This can be automated, in fact, see cabal2arch).

cabal-install will work on any system. If you have particular distro
requirements, consider distro-specific package tools.

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

[Haskell-cafe] ANN: split-0.1.1 (doc bugfix; new functions wordsBy and linesBy)

2009-01-13 Thread Brent Yorgey

Version 0.1.1 of the split library is now on Hackage, which provides a
wide range of strategies and a unified combinator framework for
splitting lists with respect to some sort of delimiter.

This version:

  * fixes a couple Haddock bugs that were preventing the documentation
from building on Hackage, and

  * adds two new convenience functions suggested by Neil Mitchell,
wordsBy and linesBy, such that

  words === wordsBy isSpace
  lines === linesBy (=='\n').

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

darcs:   http://code.haskell.org/~byorgey/code/split

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

[Haskell-cafe] Re: databases in Haskell type-safety

2009-01-13 Thread Johannes Waldmann


 Johannes http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490

 Is it just a 'fix' or HSQL will be properly maintained as well?

Just a fix for Setup.hs and *.cabal, and no changes to the real code
(w.r.t. version -1.7 presently available from hackage)

J.W.




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

[Haskell-cafe] ByteString intercalate semantics??

Hello,

 From Hoogle (my friend)  *intercalate* ::
ByteStringhttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#t%3AByteString-
[
ByteStringhttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#t%3AByteString]
- 
ByteStringhttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#t%3AByteString
Sourcehttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/src/Data-ByteString.html#intercalate
*O(n)* The 
intercalatehttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#v%3Aintercalatefunction
takes a
ByteStringhttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#t%3AByteStringand
a list of
ByteStringhttp://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString.html#t%3AByteStrings
and concatenates the list after interspersing the first argument between
each element of the list.



So intercalate doesn't do a simple concatenation?

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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

2009-01-13 Thread Magnus Therning

Don Stewart wrote:
 mle+cl:
 Don Stewart wrote:

 Well, the number one thing is to use Cabal and the cabal-install tool.
 That is the simplest way to avoid headaches.
 I'm sure cabal  works very  well for many people, but for anyone who
 has used Debian based distributions for some time,  cabal really
 does seem like a backward step.

 For instance, I regularly develop on 6 machines; personal laptop,
 home desktop, 2 work desktops and 2 work build machines.

 At work, the main output of my development work is Debian packages
 (which get installed on hundreds of machines), and the Debian packages
 I create have build depends on whatever compilers and libraries are
 required to build them. We also have a build bot that runs nightly
 in a clean chroot for each package so that build depends can  be
 verified to be correct.

 However, if I install compilers or libraries using cabal there is
 no package to build depend on, breaking a system which currently
 works very, very  well for all the code we build in C, C++ and
 Ocaml.
 
 I encourage *strongly* the Debian community to package up hackage
 packages natively, as we have done on Gentoo and Arch.
 
 (This can be automated, in fact, see cabal2arch).
 
 cabal-install will work on any system. If you have particular distro
 requirements, consider distro-specific package tools.

Get on the debian-haskell list to discuss this!  I've looked into it
myself, but got stuck on a severely outdated haddock package.  That
won't be fixed until GHC 6.10 makes it into experimental or unstable :-(

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus

Haskell is an even 'redder' pill than Lisp or Scheme.
 -- PaulPotts



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

Re: [Haskell-cafe] ByteString intercalate semantics??

vigalchin:
Hello,
 
 From Hoogle (my friend) 
 
intercalate :: [1]ByteString - [[2]ByteString] - [3]ByteString [4]Source 
O(n) The [5]intercalate function takes a [6]ByteString and a list of   
[7]ByteStrings and concatenates the list after interspersing the first 
argument between each element of the list. 
So intercalate doesn't do a simple concatenation?  

FWIW.

concat . intersperse x == intercalate x

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

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

2009-01-13 Thread Ketil Malde

Colin Adams colinpaulad...@googlemail.com writes:

 One of the wonderful things about Haskell is that almost any time anybody
 posts code, at least one person will think up an alternative but equivilent
 way of achieving the same goal - sometimes by radically different steps.

 Maybe we should have a name for this effect?

 Confusion.

Golfusion?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multiple State Monads

2009-01-13 Thread Phil

Many thanks for the replies.

Using 'modify' cleans the syntax up nicely.

With regard to using 'iterate' as shown by David here:

 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

My only concern with using this method is - Will 'iterate' not create a full
list of type [Double] and then take the final position once the list has
been fully realized?  For my application this would be undesirable as the
list may be millions of items long, and you only ever care about the last
iteration (It's a crude Monte Carlo simulator to give it some context).  If
Haskell is smart enough to look ahead and see as we only need the last
element as it is creating the list, therefore garbage collecting earlier
items then this would work fine - by I'm guessing that is a step to far for
the compiler?

I had originally implemented this similar to the above (although I didn't
know about the 'iterate' keyword - which makes things tidier - a useful
tip!), I moved to using the state monad and replicateM_ for the first
truncate(endTime/timeStep)-1 elements so that everything but the last result
is thrown away, and a final bind to getEvolution would return the result.

Now that the code has been modified so that no result is passed back, using
modify and execState, this can be simplified to replicateM_
truncate(endTime/timeStep) with no final bind needed.  I've tried this and
it works fine.

The key reason for using the Monad was to tell Haskell to discard all but
the current state.  If I'm wrong about please let me know, as I don't want
to be guilty of overcomplicating my algorithm, and more importantly it means
I'm not yet totally grasping the power of Haskell!

Thanks again,

Phil.




On 13/01/2009 03:13, David Menendez d...@zednenem.com wrote:

 On Mon, Jan 12, 2009 at 8:34 PM, Phil pbeadl...@mail2web.com 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) ) )
 

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

On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham news...@lava.net wrote:

 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.


 Maybe that was the initial reason, but I've actually found the
 Binary.Put.PutM (where Put = PutM ()) to be useful.  Sometimes
 your putter does need to propogate a result...


But that's the whole point of Writer!  Take a monoid, make it into a monad.
Put as a monad is silly.

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

[Haskell-cafe] Request for help testing HDBC-postgresql

Hi folks,

I've pushed to the Git repo a bunch of new code for HDBC-postgresql.
Specifically, it:

1) Removes autoconf in favor of Duncan's Setup.lhs that should work on
   all combinations of GHC 6.8, GHC 6.10, POSIX, and Windows

2) Adds support for UTF-8 encoding of strings

3) Adds support for translation of dates/times into a PostgreSQL format

I would appreciate people testing it on GHC 6.8, 6.10, and Windows
before I upload it to hackage.  Please reply with thumbs up/thumbs down.

Get it with:

git clone git://git.complete.org/hdbc-postgresql

Thanks!

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

[Haskell-cafe] walking a directory tree efficiently


Hi.

During a tentative (quite unsuccessfull) to convert a simple Python 
script that prints on stdout a directory and all its subdirectory [1] in 
a good Haskell (mostly to start to do real practice with the language), 
I came across this blog post:

http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o


Since recently I read about alternatives to lazy IO (like iteratee), I'm 
curious to know if a flexible, efficient and safe alternative exists, 
for the task of display a directory tree.



[1] http://paste.pocoo.org/show/99523/



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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

On Tue, 2009-01-13 at 16:33 +0100, Regis Saint-Paul wrote:
 Hi, 
 
 I’ve seen many times the monad topic coming around on the cafe and plentiful
 tutorials on monads have been published. However, as a complete Haskell
 newbie coming from OOP, I felt monads were not particularly difficult to
 grasp, and very exciting to work with. 
 
 During my experiments with Haskell so far, the main problems I kept bumping
 into were not related to the language but to its libraries: their
 compilation and installation. Unfortunately, this topic has not received
 nearly as much attention. I was unable to find a comprehensive tutorial on
 how to deal with the variety of problems I get when trying to install
 Hackage packages. This turned out to be (and still is) THE main source of
 wasted time and headaches. And worse, unlike type problems, these are not
 interesting ones to solve.

You're right, we've only been actively working on this for the last
couple years. The tools are not yet as good as we would like them to be.

Unfortunately as you say the problem does not interest a lot of people.
So it is good enough for lots of people and we do not have quite
enough people working on the package infrastructure to make it really
great as quickly as we'd like. Of course it's not for lack of ideas or
suggestions, we've got a huge TODO list! :-)

Let me add a plug for our resources for new Cabal hackers:
http://hackage.haskell.org/trac/hackage/
There's a source code guide, an easy ticket list, a link to the
development mailing list and instructions on how to get the code.

New hackers are most welcome! :-)

 Thus, as a beginner, the package management is what is really getting in the
 way of switching to Haskell--not the language. Even books like Real World
 Haskell (otherwise excellent) ignore entirely the topic.

In fairness I think it does mention Cabal and cabal-install. But it does
not go into a lot of detail I admit. At the time they were writing that
cabal-install had only just got to the stage of being usable (the
authors had to slightly make a guess as to whether this cabal-install
thing was going to become popular). It's still pretty young software.

 Cabal and Cabal-install are clearly wonderful applications that make
 installing most packages very straightforward.

Phew! That's a big improvement. It used to be universally hard to
install packages, and there were many fewer packages around because they
used to be so hard to make.

 Unfortunately, whenever this standard method for package
 installation fails (or when it is not available as with, e.g.,
 gtk2hs), I find myself in complete disarray. 

Yes, that is a serious problem.

 Below are some of the questions and issues I faced regarding package
 management: 
 
 - For a number of packages, cabal-install gets stuck and has to be killed.

Assuming you are using the latest version (0.6.0) this should never
happen. If it does please report bugs with details on how to reproduce
the problem. I'm the maintainer of Cabal so email me or add tickets in
our bug tracker:

http://hackage.haskell.org/trac/hackage/

If it gets stuck building the package then that's a slightly different
issue. Either way, more information would help in diagnosing what is
going on. It is certainly not expected behaviour.

 I assume this is due to some difficulties in solving the dependencies and it
 is fine, not all can be automated and cabal-install is not responsible for
 poor packages. But the question then becomes what to do from there? Is their
 some method to solve dependencies? How should we proceed to debug a
 package installation? How do gurus deal with that? (maybe some less known
 command line arguments? Or ways to figure out the problem and work out its
 solution (cabal-install is silent in such case)? In particular, how to know
 why did cabal get stuck in the first place?

cabal install --dry-run -v

This produces quite a bit of information about what the dependency
resolver is doing, especially in the latest version.

I've not had the situation where it sometimes fails to terminate. The
only infinite loop bug it has ever had (as far as I am aware) is when
cabal-install version 0.5.x is used with ghc-6.10. In that case it
always fails to terminate, it does not matter what package. So like I
said, if you are getting non-termination in the solver we need more
details.

What does happen sometimes is that the solver cannont find a solution.
In this case you can look at the error message and perhaps the output of
--dry-run -v and try adding constraints to give it some help on what
versions of packages to pick, for example:

cabal install --dry-run -v 'foo  2' 'bar == 1.2.0'

 - Some packages on Hackage are reported as not building successfully with
 GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
 and the later might depend on the former...What is one supposed to do in
 such case?

Note that the hackage build results are not very accurate at the moment.
They can

[Haskell-cafe] Re: The problem with Monads...

2009-01-13 Thread Benedikt Huber


Rafael Gustavo da Cunha Pereira Pinto schrieb:
Yes, I've read it twice, and it is a nice explanation that yes, the 
reader monad is an application and is a monad. How do I use it? Why not 
the function itself? How would the plumbing work in a real world example?

Hi Rafael,

First of all, I agree that the documentation for mtl should be improved.
Especially Control.Monad.RWS and Control.Monad.List really need some 
more information.


The documentation for the Reader and Identity monad are quite detailled 
though. They seem to be inspired by 
http://www.haskell.org/all_about_monads/, which also has documentation 
on Writer and Cont.


Control.Monad.List is a good example for the lack of documentation:
There is a single sentence at the beginning
 The List monad.
and then one declaration
 newtype ListT m a = ListT { runListT :: m [a] }
while the important information is hidden as one of many instance 
declarations:

 Monad m = Functor (ListT m)
 Monad m = MonadPlus (ListT m)

Btw, the quality of the examples in Control.Monad.Reader is debutable. 
From Example 1:


 -- The Reader monad, which implements this complicated check.
 calc_isCountCorrect :: Reader Bindings Bool
 calc_isCountCorrect = do
count - asks (lookupVar count)
bindings - ask
return (count == (Map.size bindings))

I think it is wrong (or weird at least) to call the function a 'Reader 
monad'; the name 'calc_isCountCorrect' is horrible too (because of the 
calc_ prefix),  Finally, implementing


 isCountCorrect :: Bindings - Bool
 isCountCorrect bs = (bs Map.! count) == Map.size bs

using the Reader monad will convince everybody _not_ to use it.

A suggestion: If license permits it, short versions of the articles on 
all_about_monads would make a great documentation for mtl (except for 
RWS and List, which are missing).


benedikt




BTW, the article is really great as an brief introduction to monad 
transformers. For the whole concept of monads, my all time favorite is 
The Haskell Programmer's Guide to the IO Monad by Stefan Klinger.


Chapters 14 to 19 of Real World Haskell also have a good introduction 
on the usage of the monads, but it lacks other monads, like the RWS or 
the Continuation...


See, that is my point. The mathematical concept of monads is very 
palatable. The idea that monads are either patterns or structures to 
hide computations in sequence is also very easy to see. But how do we 
use them?

Why should I use a Writer monad when I can use a (a,w) tuple?



On Tue, Jan 13, 2009 at 13:51, Jonathan Cast jonathancc...@fastmail.fm 
mailto:jonathancc...@fastmail.fm wrote:


On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto
wrote:
 
  Last night I was thinking on what makes monads so hard to take, and
  came to a conclusion: the lack of a guided tour on the implemented
  monads.

...

  Inspired by the paper Functional Programming with Overloading and
  Higher-Order Polymorphism,
  Mark P Jones
  (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html
http://web.cecs.pdx.edu/%7Empj/pubs/springschool.html)
Advanced School of Functional Programming, 1995.
 
  SO WHAT?

So have you read Jones' paper?  Or do you have a *concrete* explanation
of how it differs from your desired `guided tour'?

jcc





--
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.




___
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] real haskell difficulties (at least for me)

On Tue, 2009-01-13 at 16:21 +, Jamie Brandon wrote:
 I agree completely. There is not nearly enough documentation on
 packaging in haskell and too many hackage packages are broken or do
 not install. I know several people are working on improving this but
 they seem do be doing so rather quietly. Could someone briefly outline
 what improvements are planned and what stage the current work is at? I
 remember seeing some demos at anglohaskell during the summer but
 nothing since.


If you are talking about the new hackage server then the code is here:

http://code.haskell.org/hackage-server/

It should work though it is not feature complete. Patches gratefully
accepted. The build reporting should work with the current
cabal-install, though again it needs some polishing. Nothing especially
difficult, it's primarily a lack of developer time. We've got too many
high priority TODO items.

We are spread too thin across the projects: Cabal, cabal-install,
hackage-server, haskell-platform. More helpers are required.


Your Haskell needs you! Sign up today!

http://hackage.haskell.org/trac/hackage/#StartingpointsfornewCabalhackers

Duncan

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

Re: [Haskell-cafe] real haskell difficulties (at least for me)

On Tue, 2009-01-13 at 18:43 +0100, Peter Verswyvelen wrote:
 What could be done is letting the community rate the quality of the
 modules for each platform? Maybe with user comments? Like amazon.com
 (so we hackazon.org ;-)  And using lambdas instead of stars for giving
 the rating :)


On Tue, 2009-01-13 at 15:55 -0200, Mauricio wrote:
 There's a 'stability' field on cabal description files. Maybe
 it could appear after the name on the main listing. Or, all
 packages marked as 'Stable' at that field could get a beautifull
 color.


My main problem with these mechanisms is that they require a lot of
manual work and there is no way to ensure the information is accurate or
authoritative.

If what we want to know is does the package build then we should build
it and find out. We should build it on a 100 different platform
combinations and combine the information. That's what we're trying to do
with the new haskage-server and cabal-install. Lack of developer time is
hampering progress.

The stability field is almost useless. There is no agreement on what it
means and most packages lack it. If what we want to know is is this
version of the package API compatible with this one then we should
follow the package versioning policy. We should let packages opt-in to
the policy and if they op-in we should enforce it. That gives us real
information and real guarantees.

Similar comments apply for test suites and code coverage. Automation and
collection of useful information.

What human comments are great for however is describing the quality of
the API, how well it composes, how good the documentation is, how easy
it is to understand and use. That kind of information can only be
gleaned through use.

I don't know if a star/lambda rating system would be very helpful. There
are only a few similar packages in each category (even for xml and
databases). Once we eliminate the ones that clearly do not build (using
the automatically collected info) then there will only be the comments
for two or three packages to review. That's not that much and star
rating probably do not provide a very good summary to help in that
decision.

Automation! Automation! Automation!

(Oh and more hackers to help us with these vial community infrastructure
projects)

Duncan

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

Re: [Haskell-cafe] Multiple State Monads

On Tue, Jan 13, 2009 at 3:29 PM, Phil pbeadl...@mail2web.com wrote:

 My only concern with using this method is - Will 'iterate' not create a
 full
 list of type [Double] and then take the final position once the list has
 been fully realized?  For my application this would be undesirable as the
 list may be millions of items long, and you only ever care about the last
 iteration (It's a crude Monte Carlo simulator to give it some context).  If
 Haskell is smart enough to look ahead and see as we only need the last
 element as it is creating the list, therefore garbage collecting earlier
 items then this would work fine - by I'm guessing that is a step to far for
 the compiler?


No, doing this type of thing is very typical Haskell, and the garbage
collector *will* incrementally throw away early elements of the list.


 I had originally implemented this similar to the above (although I didn't
 know about the 'iterate' keyword


FWIW, iterate is just a function, not a keyword.  Could just be terminology
mismatch.

So, while the garbage collector will do the right thing, for a list millions
of elements long, I suspect you will get stack overflows and/or bad memory
performance because the computation is too lazy.  One solution is to use a
stricter version of !!, which evaluates elements of the list as it whizzes
by them.  Because the function you're iterating is strict to begin with, you
do not lose performance by doing this:

strictIdx :: Int - [a] - a
strictIdx _ [] = error empty list
strictIdx 0 (x:xs) = x
strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs

(Note that I flipped the arguments, to an order that is nicer for currying)

The reason is that iterate f x0 constructs a list like this:

[ x0, f x0, f (f x0), f (f (f x0)), ... ]

But shares the intermediate elements, so if we were to evaluate the first f
x0 to, say, 42, then the thunks are overwritten and become:

[ x0, 42, f 42, f (f 42), ... ]

So iterate f x0 !! 100 is f (f (f (f ( ... a million times ... f x0,
which will be a stack overflow because of each of the calls.  What strictIdx
does is to evaluate each element as it traverses it, so that each call is
only one function deep, then we move on to the next one.

This is the laziness abstraction leaking.  Intuition about it develops with
time and experience.  It would be great if this leak could be patched by
some brilliant theorist somewhere.

Luke

- which makes things tidier - a useful
 tip!), I moved to using the state monad and replicateM_ for the first
 truncate(endTime/timeStep)-1 elements so that everything but the last
 result
 is thrown away, and a final bind to getEvolution would return the result.

 Now that the code has been modified so that no result is passed back, using
 modify and execState, this can be simplified to replicateM_
 truncate(endTime/timeStep) with no final bind needed.  I've tried this and
 it works fine.

 The key reason for using the Monad was to tell Haskell to discard all but
 the current state.  If I'm wrong about please let me know, as I don't want
 to be guilty of overcomplicating my algorithm, and more importantly it
 means
 I'm not yet totally grasping the power of Haskell!

 Thanks again,

 Phil.




 On 13/01/2009 03:13, David Menendez d...@zednenem.com wrote:

  On Mon, Jan 12, 2009 at 8:34 PM, Phil pbeadl...@mail2web.com 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

Re: [Haskell-cafe] walking a directory tree efficiently

manlio_perillo:
 Hi.
 
 During a tentative (quite unsuccessfull) to convert a simple Python 
 script that prints on stdout a directory and all its subdirectory [1] in 
 a good Haskell (mostly to start to do real practice with the language), 
 I came across this blog post:
 http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o
 
 
 Since recently I read about alternatives to lazy IO (like iteratee), I'm 
 curious to know if a flexible, efficient and safe alternative exists, 
 for the task of display a directory tree.
 
 
 [1] http://paste.pocoo.org/show/99523/
 

If you can do it with strict IO in Python, do the same thing in Haskell
with System.IO.Strict. It should be mechanical to translate Python
programs directly into naive IO-based Haskell using strict IO. Boring,
but mechanical.

There's no iteratee/fold-based IO system yet.

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

Re: [Haskell-cafe] ANN: json-0.4.1

On Tue, 2009-01-13 at 20:58 +0100, Bas van Dijk wrote:

 Could not find module `Data.Generics':
   it was found in multiple packages: base-3.0.3.0 syb
  cabal: Error: some packages failed to install:
  json-0.4.1 failed during the building phase. The exception was:
  exit: ExitFailure 1
 
 The standard solution for this is to add a cabal flag that controls
 wether to depend on base-4 or base-3:

Note that in future it will be even easier. As of Cabal-1.6 (which comes
with ghc-6.10 but works with older versions too) you can use CPP macros:

 #if MIN_VERSION_base(4,0,0)
 import Data.Data (Data)
 #else
 import Data.Generics (Data)
 #endif

and not have to do anything in the .cabal file.

Of course this does not really help you for base 3 / 4 because the only
point of doing that is to preserve compatibility with ghc-6.8 and
out-of-the-box ghc-6.8 comes with an older Cabal version and we
generally cannot expect all users to upgrade their Cabal version.

Duncan

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

Re: [Haskell-cafe] Slow Text.JSON parser

2009-01-13 Thread Sjoerd Visscher

JSON is a UNICODE format, like any modern format is today. ByteStrings  
are not going to work.


If everybody starts yelling ByteString every time String performance  
is an issue, I don't see how Haskell is ever going to be a real world  
programming language.


On Jan 13, 2009, at 4:00 PM, Don Stewart wrote:


ketil:

Levi Greenspan greenspan.l...@googlemail.com writes:


Now I wonder why Text.JSON is so slow in comparison and what can be
done about it. Any ideas? Or is the test case invalid?


I haven't used JSON, but at first glance, I'd blame String IO.  Can't
you decode from ByteString?



Text.JSON was never optimised for performance. It was designed for  
small

JSON objects. For things above 1M I'd suggest using Data.Binary (or a
quick JSON encoding over bytestrings). Shouldn't be too hard to  
prepare.


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


--
Sjoerd Visscher
sjo...@w3future.com



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

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread George Pollard

On Tue, 2009-01-13 at 11:46 -0600, Derek Elkins wrote:
 No, it means exactly what you said it means.  People abuse it to mean
 the second sense.  Those people are wrong and there is already a term
 for that second sense, namely partial application.  I really wish
 people would stop conflating these terms*, all it does is create
 confusion.
 
 To Eugene: The suggested meaning of curriable, namely able to be
 curried, does not make sense.  curry takes an uncurried function to a
 curried form.
 
 * A related annoyance is people who talk about languages supporting
 currying and/or partial application.  Unless one means that the
 language supports higher order functions at all by that, it doesn't make
 any sense.  Haskell has no support for currying or partial
 application.  The fact that most functions are in curried form in
 Haskell is merely a convention (with, admittedly strong -social-
 ramifications.)  The only way one could say Haskell supports currying
 is that it has a lightweight notation for nested lambdas.

I’d almost say that there is no such thing as partial application in
Haskell. Since every:

 f ∷ a → b → c

is really:

 f ∷ a → (b → c)

there are no multiple arguments to be applied ‘partially’, only a
function ‘f’ that takes one argument and gives you another, anonymous,
function.

- George


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Slow Text.JSON parser

On Tue, Jan 13, 2009 at 4:39 PM, Sjoerd Visscher sjo...@w3future.comwrote:

 JSON is a UNICODE format, like any modern format is today. ByteStrings are
 not going to work.


I don't understand this statement.  Why can one not make a parser from
ByteStrings that can decode UTF-8?

Luke




 If everybody starts yelling ByteString every time String performance is
 an issue, I don't see how Haskell is ever going to be a real world
 programming language.


 On Jan 13, 2009, at 4:00 PM, Don Stewart wrote:

  ketil:

 Levi Greenspan greenspan.l...@googlemail.com writes:

  Now I wonder why Text.JSON is so slow in comparison and what can be
 done about it. Any ideas? Or is the test case invalid?


 I haven't used JSON, but at first glance, I'd blame String IO.  Can't
 you decode from ByteString?


 Text.JSON was never optimised for performance. It was designed for small
 JSON objects. For things above 1M I'd suggest using Data.Binary (or a
 quick JSON encoding over bytestrings). Shouldn't be too hard to prepare.

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


 --
 Sjoerd Visscher
 sjo...@w3future.com




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

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

Re: [Haskell-cafe] Slow Text.JSON parser

2009-01-13 Thread Sjoerd Visscher

It is not impossible, but a lot of work. And if you want to do it  
correctly you would have to support UTF-16 (BE of LE) and UTF-32 (BE  
of LE) as well. You can't expect someone to start writing utf encoders  
and decoders every time he needs a fast parser.


Sjoerd

On Jan 14, 2009, at 12:42 AM, Luke Palmer wrote:

On Tue, Jan 13, 2009 at 4:39 PM, Sjoerd Visscher  
sjo...@w3future.com wrote:
JSON is a UNICODE format, like any modern format is today.  
ByteStrings are not going to work.


I don't understand this statement.  Why can one not make a parser  
from ByteStrings that can decode UTF-8?


Luke



If everybody starts yelling ByteString every time String  
performance is an issue, I don't see how Haskell is ever going to be  
a real world programming language.



On Jan 13, 2009, at 4:00 PM, Don Stewart wrote:

ketil:
Levi Greenspan greenspan.l...@googlemail.com writes:

Now I wonder why Text.JSON is so slow in comparison and what can be
done about it. Any ideas? Or is the test case invalid?

I haven't used JSON, but at first glance, I'd blame String IO.  Can't
you decode from ByteString?


Text.JSON was never optimised for performance. It was designed for  
small

JSON objects. For things above 1M I'd suggest using Data.Binary (or a
quick JSON encoding over bytestrings). Shouldn't be too hard to  
prepare.


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

--
Sjoerd Visscher
sjo...@w3future.com




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



--
Sjoerd Visscher
sjo...@w3future.com



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

Re: [Haskell-cafe] Adding Authentication and Authorization to a service implemented in Haskell

2009-01-13 Thread Ryan Ingram

At ICFP this year there was a fun presentation about this subject.

The paper  library are available from:
http://www.cs.chalmers.se/~russo/seclib.htm

  -- ryan

2009/1/13 Daryoush Mehrtash dmehrt...@gmail.com:
 I am trying to figure out a clean way to add authentication and
 authorization in a webservice.   The services of the web services are
 implemented as Haskell functions.  The request to the service contains the
 user authentication information.   I want to authenticate the user by
 verifying his authentication informaton, assign him roles, and then based on
 the roles decide on the functions and data that he can have access too.   Is
 there a clean way to do this in Haskell?


 Thanks

 Daryoush

 ___
 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] Real World Haskell: confusion

 I'd almost say that there is no such thing as partial application in
 Haskell. Since every:

  f ∷ a → b → c

 is really:

  f ∷ a → (b → c)

 there are no multiple arguments to be applied 'partially', only a
 function 'f' that takes one argument and gives you another, anonymous,
 function.


Mmm. And since tuples are just one syntactic sugared kind of ADTs, maybe
Haskell doesn't have real currying either? ;-) Because really any kind of
ADT could be curried in a sense no? Unless we really think of tuples as a
handy anonymous kind of ADT that gets special treatment, e.g. because it is
the only way to return multiple values from a function in Haskell (without
having to declare a new type as must be done in C#, C++ etc?) Which is
probably the case...
___
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.

2009-01-13 Thread Dan Doel

On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
 On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham news...@lava.net wrote:
  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.
 
  Maybe that was the initial reason, but I've actually found the
  Binary.Put.PutM (where Put = PutM ()) to be useful.  Sometimes
  your putter does need to propogate a result...

 But that's the whole point of Writer!  Take a monoid, make it into a monad.
 Put as a monad is silly.

You mean it should be Writer instead?

When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, then 
that will be a cogent argument. Until then, one might argue that it misses 
the whole point of Put.

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

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread Anton van Straaten


Derek Elkins wrote:

No, it means exactly what you said it means.  People abuse it to mean
the second sense.  Those people are wrong and there is already a term
for that second sense, namely partial application.  I really wish
people would stop conflating these terms*, all it does is create
confusion.


+1


* A related annoyance is people who talk about languages supporting
currying and/or partial application.  Unless one means that the
language supports higher order functions at all by that, it doesn't make
any sense.  Haskell has no support for currying or partial
application.  The fact that most functions are in curried form in
Haskell is merely a convention (with, admittedly strong -social-
ramifications.)  The only way one could say Haskell supports currying
is that it has a lightweight notation for nested lambdas.


Compared to most other languages, that lightweight notation makes enough 
of a difference that it's reasonable to say that Haskell supports 
currying and partial application.


E.g., in Haskell:

  f x y z = ...

Haskell without the above notation:

  f x = \y - \z - ...

Javascript, to underscore the point:

  function f(x) { return function (y) { return function (z) { ... } } }

Standard Scheme:

  (define (f x) (lambda (y) (lambda (z) ...)))

Scheme with a common macro to support currying:

  (define (((f x) y) z) ...)

That's just the function definition side.  On the application side, 
Haskell has a lightweight notation for application in general, i.e. you 
 write f a b c instead of e.g. f(a)(b)(c) in C-like syntaxes or 
(((f a) b) c) in Lisp-like syntaxes.


Together, these two sugary treats make it quite a bit more convenient 
and practical to use currying and partial application in Haskell (and 
ML, etc.), and this translates to *much* more use in practice.


Anton

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

On Tue, Jan 13, 2009 at 5:19 PM, Dan Doel dan.d...@gmail.com wrote:

 On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
  On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham news...@lava.net wrote:
   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.
  
   Maybe that was the initial reason, but I've actually found the
   Binary.Put.PutM (where Put = PutM ()) to be useful.  Sometimes
   your putter does need to propogate a result...
 
  But that's the whole point of Writer!  Take a monoid, make it into a
 monad.
  Put as a monad is silly.

 You mean it should be Writer instead?


Or rather, PutM should not exist (or be exposed), and Put should just be a
monoid.


 When GHC starts optimizing (Writer Builder) as well as it optimizes PutM,
 then
 that will be a cogent argument. Until then, one might argue that it misses
 the whole point of Put.


Well it can still serve as an optimization over bytestrings using whatever
trickery it uses (I am assuming here -- I am not familiar with its
trickery), the same way DList is an optimization over List.  It's just that
its  monadiness is superfluous.

Surely PutM and Writer Put have almost the same performance?!  (I am worried
if not -- if not, can you give an indication why?)

Luke
___
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.

2009-01-13 Thread Dan Doel

On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
  When GHC starts optimizing (Writer Builder) as well as it optimizes PutM,
  then
  that will be a cogent argument. Until then, one might argue that it
  misses the whole point of Put.

 Well it can still serve as an optimization over bytestrings using whatever
 trickery it uses (I am assuming here -- I am not familiar with its
 trickery), the same way DList is an optimization over List.  It's just that
 its  monadiness is superfluous.

 Surely PutM and Writer Put have almost the same performance?!  (I am
 worried if not -- if not, can you give an indication why?)

The underlying monoid is Builder. The point of PutM is to be a version of 
Writer that's specialized to the Builder monoid for maximum performance. It 
looks like:

  data PairS a = PairS a {-# UNPACK #-} !Builder

  newtype PutM a = Put { unPut :: PairS a }

I'm not sure why it's split up like that. Anyhow, the strict, unpacked Builder 
gets optimized better than Writer Builder. Even if you change Writer to:

  data Writer w a = Writer a !w

it still won't match up, because polymorphic components don't get unpacked and 
such. That's, for instance, why Data.Sequence uses a specialized version of 
the finger tree type, instead of using the general version in Data.FingerTree.

Only exposing Put as a monoid is kind of redundant. You might as well work 
straight with Builder.

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

Re: [Haskell-cafe] Multiple State Monads

2009-01-13 Thread Phil

Ahh, I see  so using the State monad is arguably overcomplicating this.
This is very helpful.

The use of keyword¹ was just an unfortunate use of terminology  my bad.

Very useful explanation about the laziness resulting in stack overflows too
 when I crank up the numbers I have been seeing this, I had been
temporarily ignoring the issue and just increasing the stack size at
runtime, but I suspected something was awry.

One last question on this function:

In the definition:

mcSimulate :: Double - Double - Word64 - [Double]
mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate
startStock endTime newSeedForSeed

It is abundantly clear that the startStock and endTime are just being passed
around from call to call unchanged  that is their value is constant
throughout the the simulation.  For the purposes here when I¹m only passing
2 constants¹ around it doesn¹t strike me as too odd, but my list of
constants¹ is likely to grow as I bolt more functionality onto this.  For
readability, I understand that I can create new types to encapsulate complex
data types into a single type , but I can¹t help thinking that passing say 9
or 10 constants¹ around and around like this feels wrong¹.  If I sit back
and think about it, it doesn¹t strike me as implausible that the compiler
will recognize what I¹m doing and optimize this out for me, and what I¹m
doing is thinking about the whole think like a C++ programmer (which I
traditionally am) would.

However before I allayed my own concerns I wanted to check that in the
Haskell world passing around lots of parameters isn¹t a bad thing  that is,
I¹m not missing a trick here to make my code more readable or more
importantly more performant.

Thanks again,

Phil.

On 13/01/2009 23:24, Luke Palmer lrpal...@gmail.com wrote:

 On Tue, Jan 13, 2009 at 3:29 PM, Phil pbeadl...@mail2web.com wrote:
 My only concern with using this method is - Will 'iterate' not create a full
 list of type [Double] and then take the final position once the list has
 been fully realized?  For my application this would be undesirable as the
 list may be millions of items long, and you only ever care about the last
 iteration (It's a crude Monte Carlo simulator to give it some context).  If
 Haskell is smart enough to look ahead and see as we only need the last
 element as it is creating the list, therefore garbage collecting earlier
 items then this would work fine - by I'm guessing that is a step to far for
 the compiler?
 
 No, doing this type of thing is very typical Haskell, and the garbage
 collector will incrementally throw away early elements of the list.
 
 
 I had originally implemented this similar to the above (although I didn't
 know about the 'iterate' keyword
 
 FWIW, iterate is just a function, not a keyword.  Could just be terminology
 mismatch.
  
 So, while the garbage collector will do the right thing, for a list millions
 of elements long, I suspect you will get stack overflows and/or bad memory
 performance because the computation is too lazy.  One solution is to use a
 stricter version of !!, which evaluates elements of the list as it whizzes by
 them.  Because the function you're iterating is strict to begin with, you do
 not lose performance by doing this:
 
 strictIdx :: Int - [a] - a
 strictIdx _ [] = error empty list
 strictIdx 0 (x:xs) = x
 strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs
 
 (Note that I flipped the arguments, to an order that is nicer for currying)
 
 The reason is that iterate f x0 constructs a list like this:
 
 [ x0, f x0, f (f x0), f (f (f x0)), ... ]
 
 But shares the intermediate elements, so if we were to evaluate the first f x0
 to, say, 42, then the thunks are overwritten and become:
 
 [ x0, 42, f 42, f (f 42), ... ]
 
 So iterate f x0 !! 100 is f (f (f (f ( ... a million times ... f x0,
 which will be a stack overflow because of each of the calls.  What strictIdx
 does is to evaluate each element as it traverses it, so that each call is only
 one function deep, then we move on to the next one.
 
 This is the laziness abstraction leaking.  Intuition about it develops with
 time and experience.  It would be great if this leak could be patched by some
 brilliant theorist somewhere.
 
 Luke
 
  - which makes things tidier - a useful
 tip!), I moved to using the state monad and replicateM_ for the first
 truncate(endTime/timeStep)-1 elements so that everything but the last result
 is thrown away, and a final bind to getEvolution would return the result.
 
 Now that the code has been modified so that no result is passed back, using
 modify and execState, this can be simplified to replicateM_
 truncate(endTime/timeStep) with no final bind needed.  I've tried this and
 it works fine.
 
 The key reason for using the Monad was to tell Haskell to discard all but
 the current state.  If I'm wrong about please let me know, as I don't want
 to be guilty of overcomplicating my algorithm, and more importantly it means
 I'm

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

On Tue, 2009-01-13 at 19:19 -0500, Dan Doel wrote:
 On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
  On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham news...@lava.net wrote:
   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.
  
   Maybe that was the initial reason, but I've actually found the
   Binary.Put.PutM (where Put = PutM ()) to be useful.  Sometimes
   your putter does need to propogate a result...
 
  But that's the whole point of Writer!  Take a monoid, make it into a monad.
  Put as a monad is silly.
 
 You mean it should be Writer instead?
 
 When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, 
 then 
 that will be a cogent argument.

In that case it's a cogent argument now. :-)

You may be interested to note that PutM really is implemented as a
writer monad over the Builder monoid:

-- | The PutM type. A Writer monad over the efficient Builder monoid.
newtype PutM a = Put { unPut :: PairS a }
data PairS a = PairS a {-# UNPACK #-}!Builder

-- | Put merely lifts Builder into a Writer monad, applied to ().
type Put = PutM ()


 Until then, one might argue that it misses the whole point of Put.


Back when we were first writing the binary library, Ross converted our
original Put to be a monoid called Builder with Put left as a Writer.
GHC optimises it perfectly, we checked.

The reason we provide Put as well as Builder is purely for symmetry with
code written using Get. Also `mappend` is not so pretty. Another
argument for redefining (++) == mappend :-)

Get doesn't need to be a Monad either, it only needs to be an
applicative functor. Indeed the rules to eliminate adjacent bounds
checks only fire if it is used in this way (using  also works).

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.

2009-01-13 Thread Ross Paterson

On Tue, Jan 13, 2009 at 07:44:17PM -0500, Dan Doel wrote:
 On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
  Surely PutM and Writer Put have almost the same performance?!  (I am
  worried if not -- if not, can you give an indication why?)
 
 The underlying monoid is Builder.  The point of PutM is to be
 a version of Writer that's specialized to the Builder monoid for
 maximum performance.  It looks like:
 
   data PairS a = PairS a {-# UNPACK #-} !Builder
 
   newtype PutM a = Put { unPut :: PairS a }
 
 I'm not sure why it's split up like that.  Anyhow, the strict, unpacked
 Builder gets optimized better than Writer Builder.

But the only reason you want this monad optimized is so that you can
use it in do-notation.  Otherwise you'd just use Builder directly.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multiple State Monads

2009-01-13 Thread David Menendez

On Tue, Jan 13, 2009 at 5:29 PM, Phil pbeadl...@mail2web.com wrote:
 Many thanks for the replies.

 Using 'modify' cleans the syntax up nicely.

 With regard to using 'iterate' as shown by David here:

 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

 My only concern with using this method is - Will 'iterate' not create a full
 list of type [Double] and then take the final position once the list has
 been fully realized?

iterate creates the elements of the list as they are requested, and !!
will discard everything until it hits the answer it wants. That being
said, it's not the best way to repeatedly apply a function, as Luke
pointed out. A better way would probably be something like this,

applyNTimes :: Int - (a - a) - a - a
applyNTimes n f a
| n = 0= a
| otherwise = applyNTimes (n-1) $! f a

That ($!) is there to make sure f a gets evaluated before calling
applyNTimes again.

 The key reason for using the Monad was to tell Haskell to discard all but
 the current state.  If I'm wrong about please let me know, as I don't want
 to be guilty of overcomplicating my algorithm, and more importantly it means
 I'm not yet totally grasping the power of Haskell!

I'm not entirely sure what you mean by discard all but the current
state, but Haskell implementations are pretty good about discarding
values that are no longer needed.

That being said, here's one way I might implement your algorithm. It's
a sketch, and I haven't tested it, but the general idea should be
clear.

mcSimulate stock endTime seed = map (evolve n stock) $ iterate
(+246524) seed
where
n = truncate (endTime / timeStep)

evolve :: Int - Double - Word64 - Double
evolve n stock seed
| n = 0= stock
| otherwise = evolve (n-1) (evolveStock stock seed)
(ranq1Increment seed)

evolveStock :: Double - Word64 - Double
evolveStock stock seed = stock * exp (a + b * normalFromRngState seed)
where
a = (ir - 0.5 * vol * vol) * timeStep
b = vol * sqrt timeStep

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
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.

On Tue, 2009-01-13 at 19:44 -0500, Dan Doel wrote:
 On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
   When GHC starts optimizing (Writer Builder) as well as it optimizes PutM,
   then
   that will be a cogent argument. Until then, one might argue that it
   misses the whole point of Put.
 
  Well it can still serve as an optimization over bytestrings using whatever
  trickery it uses (I am assuming here -- I am not familiar with its
  trickery), the same way DList is an optimization over List.  It's just that
  its  monadiness is superfluous.
 
  Surely PutM and Writer Put have almost the same performance?!  (I am
  worried if not -- if not, can you give an indication why?)
 
 The underlying monoid is Builder. The point of PutM is to be a version of 
 Writer that's specialized to the Builder monoid for maximum performance. It 
 looks like:
 
   data PairS a = PairS a {-# UNPACK #-} !Builder
 
   newtype PutM a = Put { unPut :: PairS a }
 
 I'm not sure why it's split up like that. Anyhow, the strict, unpacked 
 Builder 
 gets optimized better than Writer Builder.

Oops, I walked into this conversation without reading enough context.
Sorry, I see what you mean now.

Yes, it's specialised to get decent performance. As you say, the lifted
(,) in the Writer would get in the way otherwise.

There's an interesting project in optimising parametrised monads and
stacks of monad transformers.

Duncan

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

Re: [Haskell-cafe] Multiple State Monads

On Tue, Jan 13, 2009 at 5:45 PM, Phil pbeadl...@mail2web.com wrote:

 mcSimulate :: Double - Double - Word64 - [Dou
 ble]
 mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate
 startStock endTime newSeedForSeed

 It is abundantly clear that the startStock and endTime are just being
 passed around from call to call unchanged – that is their value is constant
 throughout the the simulation.  For the purposes here when I'm only passing
 2 'constants' around it doesn't strike me as too odd, but my list of
 'constants' is likely to grow as I bolt more functionality onto this.  For
 readability, I understand that I can create new types to encapsulate complex
 data types into a single type , but I can't help thinking that passing say 9
 or 10 'constants' around and around like this 'feels wrong'.  If I sit back
 and think about it, it doesn't strike me as implausible that the compiler
 will recognize what I'm doing and optimize this out for me, and what I'm
 doing is thinking about the whole think like a C++ programmer (which I
 traditionally am) would.


You can factor out constants in a couple ways.  If you are just passing
constants between a recursive call to the same function, you can factor out
the recursive bit into a separate function:

something param1 param2 = go
where
go = ... param1 ... param2 ... etc ... go ...
etc = ...

Where go takes only the parameters that change, and the rest is handled by
its enclosing scope.  You might buy a little performance this way too,
depending on the compiler's cleverness (I'm not sure how it optimizes these
things).

If you are passing around many constants between functions, first package
them all up in a record data type:

data Params = Params {
parmFoo :: Int,
parmBar :: Double,
...
  }

At this point it is pretty easy just to pass a Parms object around.  If you
really hate the explicit style, though, you can throw your computation into
a Reader Parms  (Reader is the monad precisely for this: adding a constant
parameter to every function), and then use eg. asks parmFoo to get
parameters out.

And if none of those strike your fancy, you can look into GHC's implicit
arguments extension.  But that seems to be in the process of a phase out by
the community (nothing explicit, it's just that nobody is using them
anymore).

Luke




 However before I allayed my own concerns I wanted to check that in the
 Haskell world passing around lots of parameters isn't a bad thing – that is,
 I'm not missing a trick here to make my code more readable or more
 importantly more performant.

 Thanks again,

 Phil.


 On 13/01/2009 23:24, Luke Palmer lrpal...@gmail.com wrote:

 On Tue, Jan 13, 2009 at 3:29 PM, Phil pbeadl...@mail2web.com wrote:

 My only concern with using this method is - Will 'iterate' not create a
 full
 list of type [Double] and then take the final position once the list has
 been fully realized?  For my application this would be undesirable as the
 list may be millions of items long, and you only ever care about the last
 iteration (It's a crude Monte Carlo simulator to give it some context).  If
 Haskell is smart enough to look ahead and see as we only need the last
 element as it is creating the list, therefore garbage collecting earlier
 items then this would work fine - by I'm guessing that is a step to far for
 the compiler?


 No, doing this type of thing is very typical Haskell, and the garbage
 collector *will* incrementally throw away early elements of the list.


 I had originally implemented this similar to the above (although I didn't
 know about the 'iterate' keyword


 FWIW, iterate is just a function, not a keyword.  Could just be terminology
 mismatch.

 So, while the garbage collector will do the right thing, for a list
 millions of elements long, I suspect you will get stack overflows and/or bad
 memory performance because the computation is too lazy.  One solution is to
 use a stricter version of !!, which evaluates elements of the list as it
 whizzes by them.  Because the function you're iterating is strict to begin
 with, you do not lose performance by doing this:

 strictIdx :: Int - [a] - a
 strictIdx _ [] = error empty list
 strictIdx 0 (x:xs) = x
 strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs

 (Note that I flipped the arguments, to an order that is nicer for currying)

 The reason is that iterate f x0 constructs a list like this:

 [ x0, f x0, f (f x0), f (f (f x0)), ... ]

 But shares the intermediate elements, so if we were to evaluate the first f
 x0 to, say, 42, then the thunks are overwritten and become:

 [ x0, 42, f 42, f (f 42), ... ]

 So iterate f x0 !! 100 is f (f (f (f ( ... a million times ... f
 x0, which will be a stack overflow because of each of the calls.  What
 strictIdx does is to evaluate each element as it traverses it, so that each
 call is only one function deep, then we move on to the next one.

 This is the laziness abstraction leaking.  Intuition about it

Re: [Haskell-cafe] walking a directory tree efficiently

2009-01-13 Thread Thomas Hartman

 There's no iteratee/fold-based IO system yet.

What about

http://sites.google.com/site/haskell/notes/lazy-io-considered-harmful-way-to-go-left-fold-enumerator
?

It's not on hackage, but at least it's public domain.

Oleg, of course.



2009/1/13 Don Stewart d...@galois.com:
 manlio_perillo:
 Hi.

 During a tentative (quite unsuccessfull) to convert a simple Python
 script that prints on stdout a directory and all its subdirectory [1] in
 a good Haskell (mostly to start to do real practice with the language),
 I came across this blog post:
 http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o


 Since recently I read about alternatives to lazy IO (like iteratee), I'm
 curious to know if a flexible, efficient and safe alternative exists,
 for the task of display a directory tree.


 [1] http://paste.pocoo.org/show/99523/


 If you can do it with strict IO in Python, do the same thing in Haskell
 with System.IO.Strict. It should be mechanical to translate Python
 programs directly into naive IO-based Haskell using strict IO. Boring,
 but mechanical.

 There's no iteratee/fold-based IO system yet.

 -- Don
 ___
 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] Real World Haskell: confusion

2009-01-13 Thread wren ng thornton


Anton van Straaten wrote:

Derek Elkins wrote:
 * A related annoyance is people who talk about languages supporting
 currying and/or partial application.  Unless one means that the
 language supports higher order functions at all by that, it doesn't make
 any sense.  Haskell has no support for currying or partial
 application.  The fact that most functions are in curried form in
 Haskell is merely a convention (with, admittedly strong -social-
 ramifications.)  The only way one could say Haskell supports currying
 is that it has a lightweight notation for nested lambdas.

Compared to most other languages, that lightweight notation makes enough 
of a difference that it's reasonable to say that Haskell supports 
currying and partial application.

[...]
Together, these two sugary treats make it quite a bit more convenient 
and practical to use currying and partial application in Haskell (and 
ML, etc.), and this translates to *much* more use in practice.


The lightweight syntax for definition and application helps 
tremendously. But another thing that helps a lot is that GHC is smart 
enough to make it efficient. OCaml also has fairly lightweight syntax 
compared to Java and Scheme, but the community is strongly focused on 
performance and they tend to get riled up about when and when-not to use 
it. Whereas Haskell nurtures a community that says let the compiler do 
the ugly things, which is backed by excellent compiler writers. This 
perspective difference can also be seen in the let/letrec distinction vs 
letting the compiler figure it out.


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

Re: [Haskell-cafe] Re: databases in Haskell type-safety

2009-01-13 Thread Xie Hanjian

* John Goerzen jgoer...@complete.org [2009-01-13 12:37:45 -0600]:

 Gour wrote:
  John == John Goerzen jgoer...@complete.org writes:
  
  John That's great.  Even better if accompanied by a patch ;-)
  
  Heh, one of the things which prevents me advancing with my own Haskell
  project is lack of enough skills to provide bindings for one C-lib and
  here I see the same pattern...It looks I have to cross it over :-)
  
  I'll e.g. open ticket for BLOB support :-D
  
  John Of course :-)
  
  I did it - have you seen the notice about problems with HDBC-forums?
 
 Yes.  I am thoroughly displeased with Ruby on Rails at the moment.  It
 is less maintainable than a network of DOS boxes.  There are a host of
 mysterious crashes in Redmine at the moment -- including one where
 pulling up the page for one specific bug (but none others) crashes the
 server.
 
 I could upgrade Redmine, but that requires a Ruby stack that is partly
 newer than what's in Debian, and the upgrade for that process appears to
 succeed, but then fails in mysterious ways at the end.

Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable
releases, so I think an upgrade of your ruby stack is very reasonable.

 
 To anyone annoyed with Haskell's library install process: you have no
 idea how good you have it unless you've tried Ruby and rails.

Disagree. Rubygems is fairly easy to use. At lease, I can guess how to
uninstall a package by trying 'gem uninstall foobar', but failed by
trying 'cabal uninstall/remove foobar' :-)

Jan

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

-- 
jan=callcc{|jan|jan};jan.call(jan)


pgpW056mtnU2t.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] posting newspaper article?

Hello,

   I don't want to risk the ire of the Haskell Cafe community. Is there
a moderator? I want to post an editorial by the Big Blue CEO which seems to
me to be very
interesting vis-a-vis the FPL community and Haskell in general. I have an
online subscription and can post to stimulate discussion. 

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

Re: [Haskell-cafe] Re: databases in Haskell type-safety

Xie Hanjian wrote:
 * John Goerzen jgoer...@complete.org [2009-01-13 12:37:45 -0600]:
 
 Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable
 releases, so I think an upgrade of your ruby stack is very reasonable.

It also requires a newer version of rake than is in Debian.  Not a
problem as such, but you start working with gem install commands (and
their friends), and eventually find that after spending 30 minutes
installing/upgrading stuff, it bombs at the very end saying that some
component needed a newer version of something than is available, and it
can't install that component, so it's left the server hosed -- too new
to run the old version, not ready to accept the new.  Great.

It ought to have checked the dependencies *before* messing with my
system.  And it ought not to have failed mysteriously anyhow.

 To anyone annoyed with Haskell's library install process: you have no
 idea how good you have it unless you've tried Ruby and rails.
 
 Disagree. Rubygems is fairly easy to use. At lease, I can guess how to

It is completely poorly documented on how to gem install something when
you don't have root.  The gem(1) manpage is a joke.  The online help
doesn't help much either.   Turns out there is a magic combination of
undocumented environment variables and documented command-line options
that does it.  Or at least, I *thought* it does it.

The other problem about Rails is that code and data are inseparably
mixed.  It will be just about impossible to install a rails app as a
Debian package because it needs write access to its install directory,
and this stuff is not easily configured to use /usr and /etc as appropriate.

Anyhow, this is a Haskell list, so I'm not going to rant any more about
this here.  I can give you details off-list if you like.  It's touched a
nerve lately.

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

Re: [Haskell-cafe] Slow Text.JSON parser

2009-01-13 Thread Brandon S. Allbery KF8NH


On 2009 Jan 13, at 18:54, Sjoerd Visscher wrote:
It is not impossible, but a lot of work. And if you want to do it  
correctly you would have to support UTF-16 (BE of LE) and UTF-32 (BE  
of LE) as well. You can't expect someone to start writing utf  
encoders and decoders every time he needs a fast parser.


...whereas making a linked list of Word32 run quickly is trivial?

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


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

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread Derek Elkins

On Wed, 2009-01-14 at 12:39 +1300, George Pollard wrote:
 On Tue, 2009-01-13 at 11:46 -0600, Derek Elkins wrote:
  No, it means exactly what you said it means.  People abuse it to mean
  the second sense.  Those people are wrong and there is already a term
  for that second sense, namely partial application.  I really wish
  people would stop conflating these terms*, all it does is create
  confusion.
  
  To Eugene: The suggested meaning of curriable, namely able to be
  curried, does not make sense.  curry takes an uncurried function to a
  curried form.
  
  * A related annoyance is people who talk about languages supporting
  currying and/or partial application.  Unless one means that the
  language supports higher order functions at all by that, it doesn't make
  any sense.  Haskell has no support for currying or partial
  application.  The fact that most functions are in curried form in
  Haskell is merely a convention (with, admittedly strong -social-
  ramifications.)  The only way one could say Haskell supports currying
  is that it has a lightweight notation for nested lambdas.
 
 I’d almost say that there is no such thing as partial application in
 Haskell. Since every:
 
  f ∷ a → b → c
 
 is really:
 
  f ∷ a → (b → c)
 
 there are no multiple arguments to be applied ‘partially’, only a
 function ‘f’ that takes one argument and gives you another, anonymous,
 function.

Dan Piponi linked an LtU thread where I discussed exactly this issue.  A
slighly more direct link:
http://lambda-the-ultimate.org/node/2266#comment-33620

In Haskell there is arguably a slight semantic difference, but, yes,
there's not a big difference between application and partial application
(in Haskell.)

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

[Haskell-cafe] Re: Issues with posix-realtime package

Hi Manlio,

 Are you now talking about code in Code from HsUnix.h and execvpe.h?

Vasili

On Tue, Jan 13, 2009 at 5:09 AM, Manlio Perillo manlio_peri...@libero.itwrote:

 Galchin, Vasili ha scritto:

 [...]
I would like to help to develope any wrappers around POSIX API.


 ^^^ you are suggesting to change current wrapper API?


 No, but I don't understand why to link code that seems to be not used.

 P.S.: is the problem I have reported riproducible?

  I'm on Linux Debian Lenny.



 Manlio Perillo

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

Re: [Haskell-cafe] Real World Haskell: confusion

2009-01-13 Thread Derek Elkins

On Tue, 2009-01-13 at 19:23 -0500, Anton van Straaten wrote:
 Derek Elkins wrote:
  No, it means exactly what you said it means.  People abuse it to mean
  the second sense.  Those people are wrong and there is already a term
  for that second sense, namely partial application.  I really wish
  people would stop conflating these terms*, all it does is create
  confusion.
 
 +1
 
  * A related annoyance is people who talk about languages supporting
  currying and/or partial application.  Unless one means that the
  language supports higher order functions at all by that, it doesn't make
  any sense.  Haskell has no support for currying or partial
  application.  The fact that most functions are in curried form in
  Haskell is merely a convention (with, admittedly strong -social-
  ramifications.)  The only way one could say Haskell supports currying
  is that it has a lightweight notation for nested lambdas.
 
 Compared to most other languages, that lightweight notation makes enough 
 of a difference that it's reasonable to say that Haskell supports 
 currying and partial application.
 
 E.g., in Haskell:
 
f x y z = ...
 
 Haskell without the above notation:
 
f x = \y - \z - ...

This would be adequately lightweight for me, especially in a language
that was impure.

 
 Javascript, to underscore the point:
 
function f(x) { return function (y) { return function (z) { ... } } }

This is what my javascript looks like.  I guess I could implement some
curry functions and write:
curry3(function(x,y,z) { ... })

 
 Standard Scheme:
 
(define (f x) (lambda (y) (lambda (z) ...)))
 
 Scheme with a common macro to support currying:
 
(define (((f x) y) z) ...)
 
 That's just the function definition side.  On the application side, 
 Haskell has a lightweight notation for application in general, i.e. you 
   write f a b c instead of e.g. f(a)(b)(c) in C-like syntaxes or 
 (((f a) b) c) in Lisp-like syntaxes.
 
 Together, these two sugary treats make it quite a bit more convenient 
 and practical to use currying and partial application in Haskell (and 
 ML, etc.), and this translates to *much* more use in practice.
 
 Anton

I consider the notation f(a)(b)(c), both lightweight and ideal syntax
for C-style languages.  You really, really don't want it to look too
much like normal application in those languages as the f(a) part in
the above term can have significant side-effects, and otherwise it's
almost as minimal as Haskell* which is the most minimal possible.

I will agree that many languages have an extremely verbose syntax for
lambda abstraction.  A lightweight syntax for lambdas is very handy.  A
good example of this is Smalltalk's blocks which makes using HOFs for
all control structures reasonable.  (Smalltalk then messes things up as
far as currying is concerned by having a verbose application syntax.)
Can't account for poor tastes on the part of language designers, though
some are getting hint including Javascript's designers.  Examples:

C#2.0:
delegate(int x) { return delegate (int y) { return x + y; }; }
C#3.0:
x = y = x+y -- A lighter weight syntax for lambda than even Haskell!

JS1.7:
function(x) { return function(y) { return x + y } }
JS1.8:
function(x) function(y) x+y

* In many cases, equally minimal: f(x+1)(2*x)(x+y) Javascript or
Haskell?

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

[Haskell-cafe] endian-ness ....