Re: [Haskell-cafe] What *not* to use Haskell for

[Eelco Lempsink]

On 11 nov 2008, at 11:38, Dave Tapley wrote:

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful  
and

productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)



Working with relational databases can be a bit cumbersome.  There's  
some bitrot in the HaskellDB packages in general, so taking a more low- 
level approach seems sensible, but because the lack of extensible  
records you don't get much help from the compiler, so you need to do  
most of the checking (and 'marshalling') yourself.  In that sense,  
it's not worse than doing it with most other languages, except that  
for those languages there are often high-level libraries available to  
do, for example, cute things like object relational mapping (ORM).


--
Regards,

Eelco Lempsink



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

Re: [Haskell-cafe] What *not* to use Haskell for

[Jeremy Shaw]

At Tue, 11 Nov 2008 22:41:48 -0500,
sam lee wrote:
> 
> I haven't found multitrack audio recording applications written in
> Haskell. These are usually written in C++ using Jack audio or ASIO.
> This probably means that it is not a good idea to write real time
> audio applications in Haskell at the moment.

There are at least two Haskell bindings to JACK. I wrote one of
them. The big issue is (no surprise) garbage collection. Audio stuff
can generate a lot of garbage fast if you aren't careful. And the
stop-the-world collection can happen at unfortunate times.

The uvector library might help things -- but ultimately Haskell would
need a more realtime friendly garbage collector. 

So, realtime audio can be done in Haskell today, but is is definitely
fragile at best.

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

Re: [Haskell-cafe] What *not* to use Haskell for

[sam lee]

I haven't found multitrack audio recording applications written in
Haskell. These are usually written in C++ using Jack audio or ASIO.
This probably means that it is not a good idea to write real time
audio applications in Haskell at the moment.
So, probably avoid writing applications that use a high frequency
timer and IO that should be synchronous to the timer in Haskell.

On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton <[EMAIL PROTECTED]> wrote:
> Dave Tapley wrote:
>>
>> Hi everyone
>>
>> So I should clarify I'm not a troll and do "see the Haskell light". But
>> one thing I can never answer when preaching to others is "what does
>> Haskell not do well?"
>>
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>
> With the appropriate caveats about particular subdomains (see final
> paragraph), I wouldn't use Haskell for scripting. That is, (1) for
> Bash-style programming where 95% of the code is just invoking *nix jobs, or
> (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often
> used.
>
> Re #1: Honestly, I don't see anything other than a dedicated competitor
> being able to unseat Bourne/Bash at this task. Certainly a competitor would
> have much room for improvement-- what with being able to replace
> string-rewriting semantics with term-rewriting semantics, vastly improving
> type safety and catching innumerable bugs. However, with unsavory frequency,
> it is exactly those type-unsafe substitutions which can make shell scripting
> cleaner and more direct than a type-safe alternative. Having type safety as
> well as this sort of non-compositional structure would take a good deal of
> work to get right.
>
> Re #2: People often complain about spooky Perl that uses things like
> implicit $_ or other hidden variables. While these constructs can make any
> sizable project unmaintainable, for the quick and dirty jobs they're just
> what's needed to get things done with clarity. While ByteString code using
> regexes is just as fast in Haskell, it's often more than twice as long as
> the Perl, Sed, or Awk equivalents because many of the basic control
> structures (like Perl's -n, -p, -l,... flags) aren't already provided.
>
>
> That said, this isn't necessarily a bad thing for Haskell. "Real"
> programming languages often don't do so well in these areas (Perl being the
> exception), and they don't feel too bad about it. Both varieties of shell
> scripting are very much of the DSL nature; for programs with a significant
> amount of "actual logic" instead of mere plumbing or regexing, Haskell can
> certainly outshine these competitors. On the one hand, C and friends fight
> dirty and much work has been done so Haskell can join in on the bit-bashing
> glory. However, shell scripting is a whole different kind of imperative muck
> and very little work (that I've seen) has tried to get Haskell to jump down
> in the sewers with them.
>
> --
> Live well,
> ~wren
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What *not* to use Haskell for

[wren ng thornton]

Dave Tapley wrote:

Hi everyone

So I should clarify I'm not a troll and do "see the Haskell light". But
one thing I can never answer when preaching to others is "what does
Haskell not do well?"

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful and
productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)


With the appropriate caveats about particular subdomains (see final 
paragraph), I wouldn't use Haskell for scripting. That is, (1) for 
Bash-style programming where 95% of the code is just invoking *nix jobs, 
or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is 
often used.


Re #1: Honestly, I don't see anything other than a dedicated competitor 
being able to unseat Bourne/Bash at this task. Certainly a competitor 
would have much room for improvement-- what with being able to replace 
string-rewriting semantics with term-rewriting semantics, vastly 
improving type safety and catching innumerable bugs. However, with 
unsavory frequency, it is exactly those type-unsafe substitutions which 
can make shell scripting cleaner and more direct than a type-safe 
alternative. Having type safety as well as this sort of 
non-compositional structure would take a good deal of work to get right.


Re #2: People often complain about spooky Perl that uses things like 
implicit $_ or other hidden variables. While these constructs can make 
any sizable project unmaintainable, for the quick and dirty jobs they're 
just what's needed to get things done with clarity. While ByteString 
code using regexes is just as fast in Haskell, it's often more than 
twice as long as the Perl, Sed, or Awk equivalents because many of the 
basic control structures (like Perl's -n, -p, -l,... flags) aren't 
already provided.



That said, this isn't necessarily a bad thing for Haskell. "Real" 
programming languages often don't do so well in these areas (Perl being 
the exception), and they don't feel too bad about it. Both varieties of 
shell scripting are very much of the DSL nature; for programs with a 
significant amount of "actual logic" instead of mere plumbing or 
regexing, Haskell can certainly outshine these competitors. On the one 
hand, C and friends fight dirty and much work has been done so Haskell 
can join in on the bit-bashing glory. However, shell scripting is a 
whole different kind of imperative muck and very little work (that I've 
seen) has tried to get Haskell to jump down in the sewers with them.


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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Fraser Wilson]

I had a proof of concept lying around a couple of years ago in which a  
big complicated Ada program called a big complicated Haskell program  
and vice versa. The tricky bit from memory was making it link, and  
satisfying their rumtime initialisation requirements. No explicit C  
was required I think.


Fraser
On 11 nov 2008, at 18:09, Colin Paul Adams <[EMAIL PROTECTED]>  
wrote:



"Jake" == Jake Mcarthur <[EMAIL PROTECTED]> writes:


   Jake> Actually, that's not the whole story. I didn't realize until
   Jake> I sent it. There does exist good documentation for this, I
   Jake> promise.

Good. Let me know where it is when you track it down.

The link you pointed me too doesn't seem to address my question
directly. Also, it only talks about C.

If I want to call Haskell (and I do, perhaps) from another
garbage-collected language (Eiffel, in particular) using C as the
mutually understood language, am I not going to run into big problems?
--
Colin Adams
Preston Lancashire
___
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] compiling haskell-src-exts in 6.10

[Niklas Broberg]

2008/11/11 Hugo Pacheco <[EMAIL PROTECTED]>:
> When installing package haskell-src-exts via cabal install, I get the error
> Language/Haskell/Exts/Syntax.hs:102:7:
> Could not find module `Data.Data':
>   it is a member of package base, which is hidden
>
> However, when manually installing
> runhaskell Setup.hs configure/build/install
> It works fine
> Somehow package base is not available in cabal.. don't know why.

Like Brandon said, this is the case of cabal-install trying to be
"clever" and picking base-3 as the default even when base-4 is
available, while I in turn was trying to be "clever" in picking the
right version of base depending on which compiler was used. I'm not
sure who of us was actually the least clever, but in hindsight I think
neither was a very good choice.

I promised a new release when 6.10.1 proper was out, so here we go:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.10

Only change is that it will no longer work without the split base,
explicitly expecting base >= 4.

Cheers,

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Arnar Birgisson]

Hi again,

On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[EMAIL PROTECTED]> wrote:
> So I should clarify I'm not a troll and do "see the Haskell light". But
> one thing I can never answer when preaching to others is "what does
> Haskell not do well?"

C does extremely well when you want to write low level exploits, such
as meddling with memory, the machine stack and others.

This goes also for writing device drivers, media codecs, compression
algorithms etc. and applications that are mostly about copying bits
(with some transformations) between various memory locations.

I imagine this kind of thing would be very hard to write in Haskell.

Does that count?

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

Go Haskell! (was: [Haskell-cafe] What *not* to use Haskell for)

[Claus Reinke]

Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?


If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):

http://computer-go.org/pipermail/computer-go/2008-October/016680.html

The specification is the numbered list at the end of the message, or in the 
zip file with the Java example implementation (README). Actually, the 
interesting part from a performance perspective doesn't even require GTP 
or AMAF, just implement the random legal playouts for a 9x9 board, do 
a loop over them, keeping some basic win/loose/game length statistics.


Can you complete that in competitive speed, preferably from the specs,
without just transliterating the low-level Java code?  I won't tell you yet 
what typical playouts-per-second-per-core numbers are floating about 
for "lightly" optimised code; try to improve your code and say "stop, 
this is good enough" before comparing with the Java bot runtimes.


You'll probably have no room left for any high-level operations, ending 
up with mostly imperatively threaded array manipulations in a loop that 
is expected to be run several thousand times per real-game move (the 
idea being to run lots of dumb, but legal, simulations to the end, where 
evaluation is easy, gather statistics, then choose the move that seems 
to have the most potential). Bonus points if you can preserve any of the 
high-level advantages of working in Haskell (such as easy debuggability, 
because there will be bugs, especially if you can't afford to maintain 
redundant information representations) without sacrificing speed. (*)


As specified, the bot won't win any tournaments - it is the starting 
point (or remote ancestor) for the current champions, with lots of room 
for algorithmic improvement, not to mention actual game knowledge,
tree search and parallelization (the configurations being used for tournaments 
and exhibition games are highly parallel). The reference spec is a recent

effort, meant to provide a first milestone for aspiring Go programmers
to compare their code against, while also inviting programmers to
to show how their favourite language is eminently suitable for Go
programming (without sacrificing performance!). There are versions
in Java, D, C++, C#, and C around somewhere, possibly others.

But: please, no language evangelism on that mailing list! Those people
seem decent, peaceful and open-minded (there's even a Haskell spec
of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ).

And some of them have years (a few even decades) of experience,
much of which is made available in the mailinglist archives and
bibliography (pointers available on request - if you wanted to get
serious about playing with Go programming, you'd be expected
to mine the archives and bibliography, because just about anything
you'll come up with in your first few months will have been discussed
already;-), in spite of commercial interests and ongoing competitions.
They are already tired and wary of useless language wars (who isn't?).

Claus 
   (who has been wanting to write a Go player ever since he 
   had to decide between research and learning more Go, either 
   one trying to eat all available time and then some; perhaps I 
   should write a researcher instead, and return to playing Go?-)


(*) it would be nice if the sequential baseline performance of
   functional Haskell/Ghc arrays would be better, btw; that would
   make the ongoing work on parallel arrays much more interesting.

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

Re: [Haskell-cafe] Re: reliable (bi)directional pipe to a process

[Jason Dusek]

  As an aside, my present problem really seems to be fixed -- I
  am able to move files of more than 2MB from one process to
  another within my Haskell program. In my program, I take the
  input file, turn it into a ByteString, pass it to process one,
  capture the result as a ByteString, pass it to process two,
  caputre that result as a ByteString and then put the
  ByteString into a file. Of course we'll see whether it really
  works in the next few days here -- but after I got the forking
  right I really there's little else to be done.

  However, it's clear this has been a problem in the past. Even
  if we just use this thread to collect "incidents" -- less
  specific than bugs, but more precise than simple suggestions
  of inadequacy -- it would help everyone to know what the
  limits are with the present runtime.

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Jefferson Heard]

Kyle, I would say that most apps don't actually require that you write
a mutation heavy inner loop.   They can be written either way, and
Haskell gives you the facility to do both. Even my field, which is
visualization can be written either way.  I write with a mutation
heavy inner loop myself, because it's how I started out, and I haven't
had any trouble with performance.  OpenGL is always my upper bound.
Even 2D code, which I've written on occasion seems not to suffer.

On Tue, Nov 11, 2008 at 5:23 PM, Kyle Consalus <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
>> consalus:
>>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> wrote:
>>> > Hi everyone
>>> >
>>> > So I should clarify I'm not a troll and do "see the Haskell light". But
>>> > one thing I can never answer when preaching to others is "what does
>>> > Haskell not do well?"
>>> >
>>> > Usually I'll avoid then question and explain that it is a 'complete'
>>> > language and we do have more than enough libraries to make it useful and
>>> > productive. But I'd be keen to know if people have any anecdotes,
>>> > ideally ones which can subsequently be twisted into an argument for
>>> > Haskell ;)
>>> >
>>> > Cheers,
>>> >
>>> > Dave
>>> >
>>> > ___
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe@haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>>
>>> I think some would disagree with me, but I would advise against using
>>> haskell for a task that necessarily requires a lot of mutable state
>>> and IO and for which serious performance is a big factor.  I'm not
>>> talking about stuff that can be approximated by zippers and whatnot,
>>> but rather situations where IORefs abound and data has identity.
>>> Haskell can quite capably do mutable state and IO, but if your task is
>>> all mutable state and IO, I'd lean toward a language that makes it
>>> easier (OCaml, perhaps).
>>
>> Do you have an example of a mutable state/ IO bound application, like,
>> hmm, a window manager or a revision control system or a file system...?
>>
>> -- Don
>>
>
> Of course, with a lot of skill, good design, and a pile of language
> extensions state/io-heavy
> Haskell code can be clean and flexible. Performance can be pretty
> good, and for complex algorithmic
> code arguably a better choice than most other languages. Still,
> neither of the projects you reference (to my knowledge)
> have a mutation-heavy inner computation loop. XMonad does all of its
> mutation in a custom monad that is ReaderT StateT IO or something
> similar, and it apparently works beautifully. However, my
> understanding is that stack of monad transformers tend not to be
> particularly efficient, and while that usually isn't an issue, the
> case that I'm talking about is that where mutation
> performance is a major concern.
> Other languages offer similar expressive power, minus the joys of
> laziness and referential transparency.
> Persistent data structures are great, but if you're not using the
> persistence it is less convenient and less efficient.
> So again, Haskell _can_ do mutation and IO just fine, but if laziness,
> purity, and immutability will be the rare exception
> rather than the rule, might be easier to use a language that makes
> strictness and impurity easier.
> (Unless you're a Haskell guru, in which case I imagine Haskell is
> always the most convenient language to use).
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

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

[Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays

[Chad Scherrer]

Don Stewart  galois.com> writes:

> Hmm. So you'd need to construct a new IntMap, made by fmap'ping
> unsafeFreeze over each element of the old map.
> 

For now I'll just do

IntMap.map (unsafePerformIO . unsafeFreeze)

Hopefully this won't come back to bite me

Thanks!
Chad

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

Re: [Haskell-cafe] GHC 6.10, strange behaviour when profiling?

[Aleš Bizjak]

On Tue, 11 Nov 2008 11:54:57 +0100, Thomas Schilling  
<[EMAIL PROTECTED]> wrote:



I think you hit bug http://hackage.haskell.org/trac/ghc/ticket/2747,
which is an accounting bug in the garbage collector and goes away when
you trigger more garbage collections (which -hc does, I think).
Please file a bug report anyway, so we can verify that it is indeed
not a new bug.  (Since the profiler modifies the program it can turn
on or off different optimisations, so it's quite possible that there
are other reasons for this behaviour.)



I don't think compiling for profiling has anything to do with it because  
when
compiling with just ghc --make -O2 Test.hs and then running with -hT  
behaves as

it did with -hc and running without -hT eats up memory.
I did some further tests and it seems that this is indeed the same bug as  
above.
I will try the fix and if it doesn't fix things for me I will try to put  
together

a minimal case where this happens and file a new bug report.


Best regards, Aleš
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Trouble installing ghc-6.10.1 on linux

[Ian Lynagh]

Hi Bit,

On Mon, Nov 10, 2008 at 03:05:23PM +0200, Bit Connor wrote:
> 
> First I tried the binary version ghc-6.10.1-i386-unknown-linux.tar.bz2
> and I very quickly get this error:
> 
> $ ./configure
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> Which we'll further canonicalise into: i386-unknown-linux
> checking for path to top of build tree... configure: error: cannot
> determine current directory
> $

This probably means your libc is too old for the bindist to work.

Presumably running
utils/pwd/pwd forwardslash
gives a SIGFPE or similar?

> Next I tried building the source version ghc-6.10.1-src.tar.bz2 using
> ghc 6.6 that is already installed. configure works but make eventually
> dies with:
> 
>   ...
> Configuring ghc-6.10.1...
> cabal-bin: At least the following dependencies are missing:
> Cabal -any,

This is the output of a cabal-bin command, right? Appending -v to the
commandline might shed some light on what's going wrong. Or if that
doesn't help, try "-v 3".


Thanks
Ian

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Anatoly Yakovenko]

Has there been any progress in getting ghc set up for porting to non
x86/unix/windows platforms?  Can it generate ropi code?  It would also
be nice to be able to compile to C that rvct/arm tools can compile in
thumb mode.  Its whats stopping me from trying to use it for mobile
development.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Bulat Ziganshin]

Hello Don,

Wednesday, November 12, 2008, 1:21:18 AM, you wrote:

> If this structure is useful, you should release it on Hackage.
> You've not tested the performance though, I imagine, versus
> say, hasing into an IntMap?

you know that making all these things need a time. sorry, ATM i
think that my compression projects makes more sense, so to the Haskell
i'm just user

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Don Stewart]

consalus:
> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > consalus:
> >> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> wrote:
> >> > Hi everyone
> >> >
> >> > So I should clarify I'm not a troll and do "see the Haskell light". But
> >> > one thing I can never answer when preaching to others is "what does
> >> > Haskell not do well?"
> >> >
> >> > Usually I'll avoid then question and explain that it is a 'complete'
> >> > language and we do have more than enough libraries to make it useful and
> >> > productive. But I'd be keen to know if people have any anecdotes,
> >> > ideally ones which can subsequently be twisted into an argument for
> >> > Haskell ;)
> >> >
> >> > Cheers,
> >> >
> >> > Dave
> >> >
> >> > ___
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >>
> >> I think some would disagree with me, but I would advise against using
> >> haskell for a task that necessarily requires a lot of mutable state
> >> and IO and for which serious performance is a big factor.  I'm not
> >> talking about stuff that can be approximated by zippers and whatnot,
> >> but rather situations where IORefs abound and data has identity.
> >> Haskell can quite capably do mutable state and IO, but if your task is
> >> all mutable state and IO, I'd lean toward a language that makes it
> >> easier (OCaml, perhaps).
> >
> > Do you have an example of a mutable state/ IO bound application, like,
> > hmm, a window manager or a revision control system or a file system...?
> >
> > -- Don
> >
> 
> Of course, with a lot of skill, good design, and a pile of language
> extensions state/io-heavy Haskell code can be clean and flexible.
> Performance can be pretty good, and for complex algorithmic code
> arguably a better choice than most other languages. Still, neither of
> the projects you reference (to my knowledge) have a mutation-heavy
> inner computation loop.

Data.ByteString is full of mutation-heavy inner loops.
There's nothing magic about it.

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Kyle Consalus]

On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> consalus:
>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> wrote:
>> > Hi everyone
>> >
>> > So I should clarify I'm not a troll and do "see the Haskell light". But
>> > one thing I can never answer when preaching to others is "what does
>> > Haskell not do well?"
>> >
>> > Usually I'll avoid then question and explain that it is a 'complete'
>> > language and we do have more than enough libraries to make it useful and
>> > productive. But I'd be keen to know if people have any anecdotes,
>> > ideally ones which can subsequently be twisted into an argument for
>> > Haskell ;)
>> >
>> > Cheers,
>> >
>> > Dave
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>>
>> I think some would disagree with me, but I would advise against using
>> haskell for a task that necessarily requires a lot of mutable state
>> and IO and for which serious performance is a big factor.  I'm not
>> talking about stuff that can be approximated by zippers and whatnot,
>> but rather situations where IORefs abound and data has identity.
>> Haskell can quite capably do mutable state and IO, but if your task is
>> all mutable state and IO, I'd lean toward a language that makes it
>> easier (OCaml, perhaps).
>
> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?
>
> -- Don
>

Of course, with a lot of skill, good design, and a pile of language
extensions state/io-heavy
Haskell code can be clean and flexible. Performance can be pretty
good, and for complex algorithmic
code arguably a better choice than most other languages. Still,
neither of the projects you reference (to my knowledge)
have a mutation-heavy inner computation loop. XMonad does all of its
mutation in a custom monad that is ReaderT StateT IO or something
similar, and it apparently works beautifully. However, my
understanding is that stack of monad transformers tend not to be
particularly efficient, and while that usually isn't an issue, the
case that I'm talking about is that where mutation
performance is a major concern.
Other languages offer similar expressive power, minus the joys of
laziness and referential transparency.
Persistent data structures are great, but if you're not using the
persistence it is less convenient and less efficient.
So again, Haskell _can_ do mutation and IO just fine, but if laziness,
purity, and immutability will be the rare exception
rather than the rule, might be easier to use a language that makes
strictness and impurity easier.
(Unless you're a Haskell guru, in which case I imagine Haskell is
always the most convenient language to use).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] What *not* to use Haskell for

[Bulat Ziganshin]

Hello Don,

Wednesday, November 12, 2008, 12:51:10 AM, you wrote:

> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?

not I/O, but IO :)

btw, i use C++ for speed-critical code (compression & encryprion) and
Haskell/GHC for everything else in my FreeArc project (it has 19k
downloads ATM). i also plan to switch to C# for GUI part since gtk2hs
provides less features, less documented, les debugged, doesn't have
IDE and my partner doesnt know Haskell :)

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Don Stewart]

bulat.ziganshin:
> Hello Don,
> 
> Wednesday, November 12, 2008, 12:51:33 AM, you wrote:
> 
> >> btw, i made here some time ago proposal about pure hashtables
> 
> > Did you end up implementing this?
> 
> yes, i have published here all the 10 lines of implementation :)))
> 
> citing letter to you:
> 
> actually, writing HT module from scratch is
> very easy - all we need is a prime searching function (in order to
> establish array size). everything else:
> 
> data HT a b = HT (a->Int) (Array Int [(a,b)])
> 
> -- size is the size of array (we implent closed hash)
> -- hash is the hash function (a->Int)
> -- list is assoclist of items to put in hash
> create size hash list = HT hashfunc
>(accumArray (flip (:))
>[]
>(0, arrsize-1)
>(map (\(a,b) -> (hashfunc a,b)) list)
>)
> 
>   where arrsize =  head$ filter (>size)$ iterate (\x->3*x+1) 1
> hashfunc a  =  hash a `mod` arrsize
> 
> 
> lookup a (HT hash arr) = List.lookup a (arr!hash a)
> 
> 
> example:
> 
> main = do let assoclist = [("one", 1), ("two", 2), ("three", 3)]
>   hash = HT.create 10 Data.HashTable.hashString assoclist
>   print (HT.lookup "one" hash)
>   print (HT.lookup "zero" hash)
> 
> 

If this structure is useful, you should release it on Hackage.
You've not tested the performance though, I imagine, versus
say, hasing into an IntMap?

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

Re[2]: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Bulat Ziganshin]

Hello Don,

Wednesday, November 12, 2008, 12:51:33 AM, you wrote:

>> btw, i made here some time ago proposal about pure hashtables

> Did you end up implementing this?

yes, i have published here all the 10 lines of implementation :)))

citing letter to you:

actually, writing HT module from scratch is
very easy - all we need is a prime searching function (in order to
establish array size). everything else:

data HT a b = HT (a->Int) (Array Int [(a,b)])

-- size is the size of array (we implent closed hash)
-- hash is the hash function (a->Int)
-- list is assoclist of items to put in hash
create size hash list = HT hashfunc
   (accumArray (flip (:))
   []
   (0, arrsize-1)
   (map (\(a,b) -> (hashfunc a,b)) list)
   )

  where arrsize =  head$ filter (>size)$ iterate (\x->3*x+1) 1
hashfunc a  =  hash a `mod` arrsize


lookup a (HT hash arr) = List.lookup a (arr!hash a)


example:

main = do let assoclist = [("one", 1), ("two", 2), ("three", 3)]
  hash = HT.create 10 Data.HashTable.hashString assoclist
  print (HT.lookup "one" hash)
  print (HT.lookup "zero" hash)



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Don Stewart]

bulat.ziganshin:
> Hello Max,
> 
> Tuesday, November 11, 2008, 11:50:28 PM, you wrote:
> 
> btw, i made here some time ago proposal about pure hashtables
> implented over a pure arrays (via accumArray operaion). may be it is
> somewhat helpful for you

Did you end up implementing this?

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Don Stewart]

consalus:
> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> wrote:
> > Hi everyone
> >
> > So I should clarify I'm not a troll and do "see the Haskell light". But
> > one thing I can never answer when preaching to others is "what does
> > Haskell not do well?"
> >
> > Usually I'll avoid then question and explain that it is a 'complete'
> > language and we do have more than enough libraries to make it useful and
> > productive. But I'd be keen to know if people have any anecdotes,
> > ideally ones which can subsequently be twisted into an argument for
> > Haskell ;)
> >
> > Cheers,
> >
> > Dave
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> 
> I think some would disagree with me, but I would advise against using
> haskell for a task that necessarily requires a lot of mutable state
> and IO and for which serious performance is a big factor.  I'm not
> talking about stuff that can be approximated by zippers and whatnot,
> but rather situations where IORefs abound and data has identity.
> Haskell can quite capably do mutable state and IO, but if your task is
> all mutable state and IO, I'd lean toward a language that makes it
> easier (OCaml, perhaps).

Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Kyle Consalus]

On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> wrote:
> Hi everyone
>
> So I should clarify I'm not a troll and do "see the Haskell light". But
> one thing I can never answer when preaching to others is "what does
> Haskell not do well?"
>
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)
>
> Cheers,
>
> Dave
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

I think some would disagree with me, but I would advise against using
haskell for a task that
necessarily requires a lot of mutable state and IO and for which
serious performance is a big factor.
I'm not talking about stuff that can be approximated by zippers and
whatnot, but rather situations
where IORefs abound and data has identity. Haskell can quite capably
do mutable state and IO, but
if your task is all mutable state and IO, I'd lean toward a language
that makes it easier (OCaml, perhaps).

Also, I think there are some tasks which are more easily coded using
an OO approach, and while
this can be done in Haskell, I tend not to think it is worth the effort.
I've worked multiple projects in which big hierarchies of business
objects were used, and it had to be
easily to add new subclasses with minor variation and to treat any as
their parent. Considered by many in
FP community to be bad style, but I've never seen the equivalent
implemented in any other way effectively.
Haskell's record system gets in the way, as does the (as perceived by
me) esotericism of existential types.

Oh, also, any task that requires a good hash table. :-P

Mind you, Haskell is my first choice for a leisure project and I think
it is an excellent choice for
quite a few tasks and still capable of what I list above, just not in
my opinion the best choice.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Bulat Ziganshin]

Hello Max,

Tuesday, November 11, 2008, 11:50:28 PM, you wrote:

btw, i made here some time ago proposal about pure hashtables
implented over a pure arrays (via accumArray operaion). may be it is
somewhat helpful for you


>>> > using unsafeFreeze. I'm getting stuck here, since the
>>> IntMap library
>>> > is not so monad-friendly.
>>>
>>> Data.Hashtable is
>>
>> Well, I need mutable update for a while... after that, I prefer a pure
>> interface, which is why I'm trying to freeze all the values.

> Is there any reason why an immutable Hashtable shouldn't be
> implemented, with a pure interface, such that hashtables can be
> (unsafe)Freezed into immutable hashtables? Would this be useful?

> --Max


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] Compilation issue with GHC 6.10.1 on Vista

[Alexey Romanov]

I'm trying to update FreshLib
 to work
with the current GHC version.
Now it works fine in GHCi, but trying to compile with ghc --make gives
this result:

[1 of 5] Compiling NominalBase  ( NominalBase.hs, NominalBase.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package base-3.0.3.0 ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package containers-0.2.0.0 ... 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 syb-with-class-0.4 ... linking ... done.
C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s: Assembler messages:
C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:557: Error: symbol `_N
ominalBase_zdgtoName_closure' is already defined
C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:585: Error: symbol `_N
ominalBase_zdgtoName_info' is already defined
C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:637: Error: symbol `_N
ominalBase_zdgfromName_closure' is already defined
C:\Users\Alexey\AppData\Local\Temp\/ghc1892_0/ghc1892_0.s:665: Error: symbol `_N
ominalBase_zdgfromName_info' is already defined

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

RE: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Scherrer, Chad]

Bulat wrote:
> Hello Chad,
> 
> Tuesday, November 11, 2008, 10:23:09 PM, you wrote:
> > using unsafeFreeze. I'm getting stuck here, since the 
> IntMap library 
> > is not so monad-friendly.
> 
> Data.Hashtable is

Well, I need mutable update for a while... after that, I prefer a pure
interface, which is why I'm trying to freeze all the values. 

Anyway, I haven't used hashtables in Haskell, but I vaguely remember
some discussion about them being really slow. Is this no longer the
case?

I guess if I really need to go this route I could try out HsJudy or
something.

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

Re: [Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays

[Ross Paterson]

On Tue, Nov 11, 2008 at 07:39:53PM +, Chad Scherrer wrote:
> Don Stewart  galois.com> writes:
> > Hmm. So you'd need to construct a new IntMap, made by fmap'ping
> > unsafeFreeze over each element of the old map.
> 
> I guess if we had a Traversable instance for Data.IntMap things would be just
> fine. Would this be a bad thing in any way?

I don't think so.  It's a straightforward instance, and its omission was
an oversight.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Bulat Ziganshin]

Hello Chad,

Tuesday, November 11, 2008, 10:23:09 PM, you wrote:
> using unsafeFreeze. I'm getting stuck here, since the IntMap library is not so
> monad-friendly. 

Data.Hashtable is


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] problem with boolean splicing in templates in ghc 6.10.1

[Leonidas Fegaras]

Seems that boolean splicing in haskell templates in ghc 6.10.1 does not
work correctly. If you do:

$((\b -> [| b |]) True)

you get the error:

Can't find interface-file declaration for data constructor GHC.Base.True
  Probable cause: bug in .hi-boot file, or inconsistent .hi file
  Use -ddump-if-trace to get an idea of which file caused the error

It seems that GHC.Base.True is now GHC.Bool.True, but the splicing code
still generates the former.
Leonidas Fegaras


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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Colin Paul Adams]

> "John" == John Goerzen <[EMAIL PROTECTED]> writes:

>> Read the FFI Report.  It is relatively readable and
>> comprehensive.  http://www.cse.unsw.edu.au/~chak/haskell/ffi/
>> 
>> And yes, you will have to use C as an intermediary, though you
>> may not have to actually write any C.  You simply expose the
>> Haskell functions in whatever form the other language expects.
>> You'll almost certainly have to write marshalling code of some
>> sort.

John> I often like to look at these situations as an opportunity
John> to introduce modularity and piping.  Do you really need them
John> running in the same address space?

Good point.

And thanks everyone for your help. I have enough to go on now.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Calling Haskell from other languages?

[Don Stewart]

colin:
> > "Jake" == Jake Mcarthur <[EMAIL PROTECTED]> writes:
> 
> Jake> Actually, that's not the whole story. I didn't realize until
> Jake> I sent it. There does exist good documentation for this, I
> Jake> promise.
> 
> Good. Let me know where it is when you track it down.
> 
> The link you pointed me too doesn't seem to address my question
> directly. Also, it only talks about C.
> 
> If I want to call Haskell (and I do, perhaps) from another
> garbage-collected language (Eiffel, in particular) using C as the
> mutually understood language, am I not going to run into big problems?

No, you can manage objects via e.g. ForeignPtr's. The community
has a whole has done bridges between Haskell and pretty much anything
you care to name, via the C FFI. Just depends on how well you understand
the memory management models of both players.

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

[Haskell-cafe] Re: mapping unfreeze over an IntMap of IOUArrays

[Chad Scherrer]

Don Stewart  galois.com> writes:
> Hmm. So you'd need to construct a new IntMap, made by fmap'ping
> unsafeFreeze over each element of the old map.

I guess if we had a Traversable instance for Data.IntMap things would be just
fine. Would this be a bad thing in any way?

Chad

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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Don Stewart]

colin:
> Is there a way to call Haskell code from other languages? I have looked on
> the wiki, and as far as I can see, it only talks about the other way
> round (when Haskell is the main program).

http://haskell.org/haskellwiki/Calling_Haskell_from_C

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

Re: [Haskell-cafe] Problem installing curl

[Duncan Coutts]

On Tue, 2008-11-11 at 10:49 -0800, Don Stewart wrote:

> > curl-1.3.2.1 failed during the configure step. The exception was:
> > sh: runGenProcess: does not exist (No such file or directory)
> > 
> > I don't know what to do here. Can anybody help me please?
> > 
> > I'm using the brand new GHC 6.10.1 on Windows Vista.
> > 
> > Best regards,
> > 
> 
> Do you  have the curl C library installed?

The first problem is that curl uses a configure script and that needs
'sh' which needs mingw+msys or cygwin. That's what the error message is
obliquely reporting.

After that the next problem will be having the curl C lib installed.

> Either way, that error message from Cabal isn't very good. Duncan?

Filed: http://hackage.haskell.org/trac/hackage/ticket/403

It should be easy to fix. It's a nice simple bug for some new Cabal
contributor.

Speaking of Cabal contributors, we're a little short of them at the
moment. I welcome people to check out our list of easy tickets:

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

And to see the guide to the code base:

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


Duncan

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

Re: [Haskell-cafe] Calling Haskell from other languages?

[John Goerzen]

On Tue, Nov 11, 2008 at 12:35:05PM -0600, Derek Elkins wrote:
> On Tue, 2008-11-11 at 17:09 +, Colin Paul Adams wrote:
> > > "Jake" == Jake Mcarthur <[EMAIL PROTECTED]> writes:
> > 
> > Jake> Actually, that's not the whole story. I didn't realize until
> > Jake> I sent it. There does exist good documentation for this, I
> > Jake> promise.
> > 
> > Good. Let me know where it is when you track it down.
> > 
> > The link you pointed me too doesn't seem to address my question
> > directly. Also, it only talks about C.
> > 
> > If I want to call Haskell (and I do, perhaps) from another
> > garbage-collected language (Eiffel, in particular) using C as the
> > mutually understood language, am I not going to run into big problems?
> 
> Read the FFI Report.  It is relatively readable and comprehensive.
> http://www.cse.unsw.edu.au/~chak/haskell/ffi/
> 
> And yes, you will have to use C as an intermediary, though you may not
> have to actually write any C.  You simply expose the Haskell functions
> in whatever form the other language expects.  You'll almost certainly
> have to write marshalling code of some sort.

I often like to look at these situations as an opportunity to
introduce modularity and piping.  Do you really need them running in
the same address space?


> 
> ___
> 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] mapping unfreeze over an IntMap of IOUArrays

[Don Stewart]

chad.scherrer:
> Hello cafe,
> 
> I've hit a bit of a monadic snag here...
> 
> I'm scanning a big file, building a table of statistics. I end up with
> something like
> 
> IO (IntMap (IOUArray Int Double))
> 
> Once I've read in the whole file and built my statistics, I don't need
> any more updates, so I'd like to do something like
> 
> IntMap (IOUArray Int Double) -> IO (IntMap (UArray Int Double)),
> 
> using unsafeFreeze. I'm getting stuck here, since the IntMap library
> is not so monad-friendly. 

Hmm. So you'd need to construct a new IntMap, made by fmap'ping
unsafeFreeze over each element of the old map.

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

[Haskell-cafe] mapping unfreeze over an IntMap of IOUArrays

[Chad Scherrer]

Hello cafe,

I've hit a bit of a monadic snag here...

I'm scanning a big file, building a table of statistics. I end up with something
like

IO (IntMap (IOUArray Int Double))

Once I've read in the whole file and built my statistics, I don't need any more
updates, so I'd like to do something like

IntMap (IOUArray Int Double) -> IO (IntMap (UArray Int Double)),

using unsafeFreeze. I'm getting stuck here, since the IntMap library is not so
monad-friendly. 

I could rebuild the whole thing using sequence and lists, but the table is
pretty big (4.5 million keys on a first run), so I'd prefer to avoid that. Any
ideas?

BTW, I probably "should" be using ST for this, but I hit the usual "type s
escapes" irritation and gave up. If that would work more easily, that would be
fine with me too.

Thanks!

Chad Scherrer

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

Re: [Haskell-cafe] Problem installing curl

[Don Stewart]

huschi:
> Hi all,
> 
> when I try to install curl (needed for hxt) using "cabal install curl" I 
> alwas get the following error message:
> 
> 
> Resolving dependencies...
> 'curl-1.3.2.1' is cached.
> Configuring curl-1.3.2.1...
> cabal: Error: some packages failed to install:
> curl-1.3.2.1 failed during the configure step. The exception was:
> sh: runGenProcess: does not exist (No such file or directory)
> 
> 
> I don't know what to do here. Can anybody help me please?
> 
> I'm using the brand new GHC 6.10.1 on Windows Vista.
> 
> Best regards,
> 

Do you  have the curl C library installed?

Either way, that error message from Cabal isn't very good. Duncan?

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

Re: [Haskell-cafe] compilation question

[Derek Elkins]

On Tue, 2008-11-11 at 18:49 +0100, Peter Padawitz wrote:
> At first a type of arithmetic expressions and its generic evaluator:
> 
> data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- 
> Expr |
> Int :* Expr | Expr :^ Int
> 
> data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> a, sum_ :: 
> [a] -> a,
>   prod :: [a] -> a, sub :: a -> a -> a,
>   scal :: Int -> a -> a, expo :: a -> Int -> a}
> 
> eval :: ExprAlg a -> Expr -> a
> eval alg (Con i)   = con alg i
> eval alg (Var x)   = var alg x
> eval alg (Sum es)  = sum_ alg (map (eval alg) es)
> eval alg (Prod es) = prod alg (map (eval alg) es)
> eval alg (e :- e') = sub alg (eval alg e) (eval alg e')
> eval alg (n :* e)  = scal alg n (eval alg e)
> eval alg (e :^ n)  = expo alg (eval alg e) n
> 
> Secondly, a procedural version of eval (in fact based on continuations):
> 
> data Id a = Id {out :: a} deriving Show
> 
> instance Monad Id where (>>=) m = ($ out m); return = Id
> 
> peval :: ExprAlg a -> Expr -> Id a
> peval alg (Con i)   = return (con alg i)
> peval alg (Var x)   = return (var alg x)
> peval alg (Sum es)  = do as <- mapM (peval alg) es; return (sum_ alg as)
> peval alg (Prod es) = do as <- mapM (peval alg) es; return (prod alg as)
> peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return 
> (sub alg a b)
> peval alg (n :* e)  = do a <- peval alg e; return (scal alg n a)
> peval alg (e :^ n)  = do a <- peval alg e; return (expo alg a n)
> 
> My question: Is peval less time- or space-consuming than eval? Or would 
> ghc, hugs et al. optimize eval towards peval by themselves?

peval is not based on continuations.  As you state, you are using the Id
monad.  (>>=) is just flip ($).  Unless GHC has some trouble seeing
through the Monad instance, it should simply inline the latter to the
former since they are the exact same code.

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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Derek Elkins]

On Tue, 2008-11-11 at 17:09 +, Colin Paul Adams wrote:
> > "Jake" == Jake Mcarthur <[EMAIL PROTECTED]> writes:
> 
> Jake> Actually, that's not the whole story. I didn't realize until
> Jake> I sent it. There does exist good documentation for this, I
> Jake> promise.
> 
> Good. Let me know where it is when you track it down.
> 
> The link you pointed me too doesn't seem to address my question
> directly. Also, it only talks about C.
> 
> If I want to call Haskell (and I do, perhaps) from another
> garbage-collected language (Eiffel, in particular) using C as the
> mutually understood language, am I not going to run into big problems?

Read the FFI Report.  It is relatively readable and comprehensive.
http://www.cse.unsw.edu.au/~chak/haskell/ffi/

And yes, you will have to use C as an intermediary, though you may not
have to actually write any C.  You simply expose the Haskell functions
in whatever form the other language expects.  You'll almost certainly
have to write marshalling code of some sort.

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

Re: [Haskell-cafe] compiling haskell-src-exts in 6.10

[Brandon S. Allbery KF8NH]

On 2008 Nov 11, at 7:20, Hugo Pacheco wrote:
When installing package haskell-src-exts via cabal install, I get  
the error


Language/Haskell/Exts/Syntax.hs:102:7:
Could not find module `Data.Data':
  it is a member of package base, which is hidden


However, when manually installing

runhaskell Setup.hs configure/build/install

It works fine
Somehow package base is not available in cabal.. don't know why.


I think what this really means is that "cabal install" is using base-3  
whereas direct installation is using base-4, or vice versa.  dcoutts  
or the haskell-src-exts maintainer would have to tell you what to do  
about it though.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

[Haskell-cafe] Problem installing curl

[Martin Huschenbett]

Hi all,

when I try to install curl (needed for hxt) using "cabal install curl" I 
alwas get the following error message:



Resolving dependencies...
'curl-1.3.2.1' is cached.
Configuring curl-1.3.2.1...
cabal: Error: some packages failed to install:
curl-1.3.2.1 failed during the configure step. The exception was:
sh: runGenProcess: does not exist (No such file or directory)


I don't know what to do here. Can anybody help me please?

I'm using the brand new GHC 6.10.1 on Windows Vista.

Best regards,

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

RE: [Haskell-cafe] compilation question

[Mitchell, Neil]

Hi

The one way to test this is to benchmark, everything else will just be
peoples random guesses.

As for my random guess, eval should be significantly faster than peval
in Hugs, and probably slightly faster than peval in GHC. I don't see why
you think peval is efficient - monads /= efficiency, they merely are an
extra layer over standard evaluation. If you use the IO monad and some
careful annotations you could hope to draw with eval, but just accept
the beauty that is pure functional programming and smile :-)

Thanks

Neil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Padawitz
> Sent: 11 November 2008 5:49 pm
> To: haskell-cafe@haskell.org
> Cc: Hubert Wagner
> Subject: [Haskell-cafe] compilation question
> 
> At first a type of arithmetic expressions and its generic evaluator:
> 
> data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- 
> Expr |
> Int :* Expr | Expr :^ Int
> 
> data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> 
> a, sum_ :: 
> [a] -> a,
>   prod :: [a] -> a, sub :: a -> a -> a,
>   scal :: Int -> a -> a, expo :: a -> Int -> a}
> 
> eval :: ExprAlg a -> Expr -> a
> eval alg (Con i)   = con alg i
> eval alg (Var x)   = var alg x
> eval alg (Sum es)  = sum_ alg (map (eval alg) es)
> eval alg (Prod es) = prod alg (map (eval alg) es)
> eval alg (e :- e') = sub alg (eval alg e) (eval alg e')
> eval alg (n :* e)  = scal alg n (eval alg e)
> eval alg (e :^ n)  = expo alg (eval alg e) n
> 
> Secondly, a procedural version of eval (in fact based on 
> continuations):
> 
> data Id a = Id {out :: a} deriving Show
> 
> instance Monad Id where (>>=) m = ($ out m); return = Id
> 
> peval :: ExprAlg a -> Expr -> Id a
> peval alg (Con i)   = return (con alg i)
> peval alg (Var x)   = return (var alg x)
> peval alg (Sum es)  = do as <- mapM (peval alg) es; return 
> (sum_ alg as)
> peval alg (Prod es) = do as <- mapM (peval alg) es; return 
> (prod alg as)
> peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return 
> (sub alg a b)
> peval alg (n :* e)  = do a <- peval alg e; return (scal alg n a)
> peval alg (e :^ n)  = do a <- peval alg e; return (expo alg a n)
> 
> My question: Is peval less time- or space-consuming than 
> eval? Or would 
> ghc, hugs et al. optimize eval towards peval by themselves?
> 
> Peter
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

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

[Haskell-cafe] compilation question

[Peter Padawitz]

At first a type of arithmetic expressions and its generic evaluator:

data Expr = Con Int | Var String | Sum [Expr] | Prod [Expr] | Expr :- 
Expr |

   Int :* Expr | Expr :^ Int

data ExprAlg a = ExprAlg {con :: Int -> a, var :: String -> a, sum_ :: 
[a] -> a,

 prod :: [a] -> a, sub :: a -> a -> a,
 scal :: Int -> a -> a, expo :: a -> Int -> a}
   
eval :: ExprAlg a -> Expr -> a

eval alg (Con i)   = con alg i
eval alg (Var x)   = var alg x
eval alg (Sum es)  = sum_ alg (map (eval alg) es)
eval alg (Prod es) = prod alg (map (eval alg) es)
eval alg (e :- e') = sub alg (eval alg e) (eval alg e')
eval alg (n :* e)  = scal alg n (eval alg e)
eval alg (e :^ n)  = expo alg (eval alg e) n

Secondly, a procedural version of eval (in fact based on continuations):

data Id a = Id {out :: a} deriving Show

instance Monad Id where (>>=) m = ($ out m); return = Id

peval :: ExprAlg a -> Expr -> Id a
peval alg (Con i)   = return (con alg i)
peval alg (Var x)   = return (var alg x)
peval alg (Sum es)  = do as <- mapM (peval alg) es; return (sum_ alg as)
peval alg (Prod es) = do as <- mapM (peval alg) es; return (prod alg as)
peval alg (e :- e') = do a <- peval alg e; b <- peval alg e'; return 
(sub alg a b)

peval alg (n :* e)  = do a <- peval alg e; return (scal alg n a)
peval alg (e :^ n)  = do a <- peval alg e; return (expo alg a n)

My question: Is peval less time- or space-consuming than eval? Or would 
ghc, hugs et al. optimize eval towards peval by themselves?


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

Re: [Haskell-cafe] What *not* to use Haskell for

[Jules Bean]

Malcolm Wallace wrote:

Jules Bean <[EMAIL PROTECTED]> wrote:


GHC's scheduler lacks any hard timeliness guarantees.

This is probably not a fundamental problem with haskell. It's a
problem  with the compiler/RTS which we happen to be using.


Actually, I would say it is much worse than that.  It is not merely a
question of implementation.  We do not have _any_ predictable theory of
resource usage (time, memory) for a lazy language.  There is no analysis
(yet) which can look at an arbitrary piece of Haskell code and tell you
how long it will take to execute, or how much heap/stack it will eat.
What is more, it is very hard to do that in a modular way.  The
execution time of lazy code is entirely dependent on its usage/demand
context.  So you can't just apply WCET to single functions, then combine
the results.


That's true but I'm not sure you need to solve that (hard, interesting) 
problem just to get *some* kind of timeliness guarantees.


For example the guarantee that a thread is woken up within 10us of the 
MVar it was sleeping on being filled doesn't require you to solve the 
whole problem. It requires you to be able to bound GC time, or preempt 
the GC, but that's feasible isn't it?


Then there is the possibility of a strict DSL (probably but not 
necessarily a Monad) within haskell which has strong timeliness guarantees.


Jules


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

Re[2]: [Haskell-cafe] Calling Haskell from other languages?

[Bulat Ziganshin]

Hello Colin,

Tuesday, November 11, 2008, 8:09:09 PM, you wrote:

> If I want to call Haskell (and I do, perhaps) from another
> garbage-collected language (Eiffel, in particular) using C as the
> mutually understood language, am I not going to run into big problems?

of course not. there will be two independent heaps. of course you
can't directly send pointers to gc-collected structures between two
languages, they should be converted through buffers in C world
(i.e. malloced ones)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Colin Paul Adams]

> "Jake" == Jake Mcarthur <[EMAIL PROTECTED]> writes:

Jake> Actually, that's not the whole story. I didn't realize until
Jake> I sent it. There does exist good documentation for this, I
Jake> promise.

Good. Let me know where it is when you track it down.

The link you pointed me too doesn't seem to address my question
directly. Also, it only talks about C.

If I want to call Haskell (and I do, perhaps) from another
garbage-collected language (Eiffel, in particular) using C as the
mutually understood language, am I not going to run into big problems?
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Calling Haskell from other languages?

[Donn Cave]

Quoth Colin Paul Adams <[EMAIL PROTECTED]>:

| Is there a way to call Haskell code from other languages? I have looked on
| the wiki, and as far as I can see, it only talks about the other way
| round (when Haskell is the main program).

There sure is a way to call from other languages - cf. "foreign export" -
but don't know how hard it would be to make Haskell live without its "main",
which performs a lot of runtime initialization.

For me (with nhc98) it's a lot easier to use a Haskell "main" that's just
a brief wrapper:

  module Main (main) where
  import NHC.FFI

  foreign import ccall "cmain" cmain :: IO ()

  main = cmain

(... where "cmain" is an external entry point in the C code, which can
then call Haskell as required.)

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

Re: [Haskell-cafe] Calling Haskell from other languages?

[Jake Mcarthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually, that's not the whole story. I didn't realize until I sent  
it. There does exist good documentation for this, I promise.


- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkZuHoACgkQye5hVyvIUKnGeACfZN+9nNy+nGvQHDsG1FrI4Puu
Zw0AmgKK0WOYTjWWeQX93rrnSJApG0pa
=Vazy
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Calling Haskell from other languages?

[Jake Mcarthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 11, 2008, at 10:45 AM, Colin Paul Adams wrote:

Is there a way to call Haskell code from other languages? I have  
looked on

the wiki, and as far as I can see, it only talks about the other way
round (when Haskell is the main program).


http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Calling_Haskell_from_C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkZuCkACgkQye5hVyvIUKk1pwCfRbVnERADZPygCNX2wjNkdQOC
FXMAoKodV1TitVzr5ZJF/AUSmCXuRuKY
=BUkK
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Calling Haskell from other languages?

[Colin Paul Adams]

Is there a way to call Haskell code from other languages? I have looked on
the wiki, and as far as I can see, it only talks about the other way
round (when Haskell is the main program).
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] announce: Workflow-0.1

[Alberto G. Corona]

I needed to to define multiuser web workflows in the most transparent way. I
wondered if a state monad could transparently bring automatic checkpointing
of each action and automatic resume after failure. In this way a long living
computation could be expressed in a single monadic computation.

Additionally,  for inter process communications,  this package  includes a
primitive for  activating a workflow whenever any action result meet certain
condition. There are also primitives for start/restart processes,  retrieval
of intermediate results and unsafe IO actions inside the state monad...

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


Cabal description:

Transparent low level support (state logging, resume of the computation,
wait for data condition) for long living, event driven processes.

 Workflow give the two first services to any monadic computation of type
(a-> m a) usually m=IO

f x >>=\x'-> g x' >>= \x''->... z

by prefixing the user with the method "step":

step f x >>= \x'-> step g x' >>= \x''->...

This means that a workflow can be described with the familiar "do" notation.
In principle, there is no other limitation on the syntax but the restriction
(a -> m a): All computations consume and produce the same type of data. do
notation is supported fully.




Workflow export a few primitives that bring the following services:

- transparent checkpointing of each step in permanent storage using TCache
(step)
- resume of the monadic computation at the last checkpoint after soft or
hard interruption
- use of versioning techniques for storing object changes (using
RefSerialize)
- retrieval of the object at any previous step
- suspend the computation (waitFor) until the input object meet certain
conditions. useful for inter-workflow comunications.


At the end of the workflow all the intermediate data is erased. see demos
and the header of Control.TCache for documentation.


This is a piece of code is a loop that imput numbers (demo.hs). there is
another process, that check the numbers entered and return Finish when match
the desired number. that is detected by this thread and finalize. When
number of tries are 9, The process finish, this is detected by the other
process and finalizes also.
That ilustrates the use of event handling (waitFor) and step execution.


askNumbers name d = do
  step2 $  threadDelay 5000   --
wait for the other tread to process.

  r <- step (waitFor anything) d   --
get the last value of the object with key "try-finish", to look for the
other thread actions
  case r of

   Finish msg ->  step2 $ print
msg   --the
other thread sent a finalize response

   Try 9 num  ->  step1 $ return $ Finish  "sorry, no more
guesses" --send finalization to the wait thread

   _ -> do
 nd <- step  (askNumber name) d
 askNumbers name nd
  where
  anything= \_-> True
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ByteString/parsec

[Christian Maeder]

Pieter Laeremans wrote:
> fileParser :: Parser Content
> fileParser = do
> title <- manyTill getInput  (string . pack "\nTITLE\n")
> author <- manyTill getInput (string. pack "\nTITLE\n")
> 
> return Content title author ...
> 
> But this doesn't work.

"getInput" does not consume any input but just returns the remaining
input. Therefore it is called infinitely often. If your input were
String you could use "anyChar" instead. I don't know how to do it with
ByteString (maybe parsec-3?).

> I get a stack overflow.  Obviously I'm not understanding something here.
> Are there any good examples of open source projects which parse
> ByteString data ?
> 
> thanks in advance,

Cheers Christian

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Malcolm Wallace]

Jules Bean <[EMAIL PROTECTED]> wrote:

> GHC's scheduler lacks any hard timeliness guarantees.
> 
> This is probably not a fundamental problem with haskell. It's a
> problem  with the compiler/RTS which we happen to be using.

Actually, I would say it is much worse than that.  It is not merely a
question of implementation.  We do not have _any_ predictable theory of
resource usage (time, memory) for a lazy language.  There is no analysis
(yet) which can look at an arbitrary piece of Haskell code and tell you
how long it will take to execute, or how much heap/stack it will eat.
What is more, it is very hard to do that in a modular way.  The
execution time of lazy code is entirely dependent on its usage/demand
context.  So you can't just apply WCET to single functions, then combine
the results.

It's a question I'd love to be able to solve, but I note that those who
are currently working on predictable execution of functional languages
(e.g. the Hume project) have already ditched laziness in favour of
eager execution.

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

[Haskell-cafe] ByteString/parsec

[Pieter Laeremans]

HI,

I want to efficiently parse  a large collections of files.

The files are in the format :

example title
TITLE
author name
AUTHOR
some lines with summary here
SUMMARY
the real text
TEXT
a list of links
LINKS

I want to use "ByteString" here, but which library should I use to
parse ? "attoparsec" or "bytestringparser",
both export the same interface.

When I use one of these I thaught it would be nice to write something
like this :

fileParser :: Parser Content
fileParser = do
title <- manyTill getInput  (string . pack "\nTITLE\n")
author <- manyTill getInput (string. pack "\nTITLE\n")

return Content title author ...

But this doesn't work.

Even on a small example :

 parseTest (manyTill getInput (string $ pack "SPLIT")  (pack "split
the text at SPLIT part two")

I get a stack overflow.  Obviously I'm not understanding something here.
Are there any good examples of open source projects which parse
ByteString data ?

thanks in advance,

Pieter

-- 
Pieter Laeremans <[EMAIL PROTECTED]>

"The future is here. It's just not evenly distributed yet."  W. Gibson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What *not* to use Haskell for

[Robert Greayer]

--- On Tue, 11/11/08, Dave Tapley <[EMAIL PROTECTED]> wrote:
> So I should clarify I'm not a troll and do "see
> the Haskell light". But
> one thing I can never answer when preaching to others is
> "what does
> Haskell not do well?"
> 

'Hard' real-time applications?  I don't know that there couldn't be a 
'real-time friendly' Haskell, but for some applications, the unpredictability 
(however slight) of when, for example, garbage collection happens, or how long 
it takes, is unacceptable. (Even the unpredictability of heap 
allocation/deallocation a la malloc/free is unacceptable for some real time 
apps).  Haskell is in the same boat here with lots of other languages, of 
course.


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

Re[2]: [Haskell-cafe] Re: What *not* to use Haskell for

[Bulat Ziganshin]

Hello Jefferson,

Tuesday, November 11, 2008, 4:12:40 PM, you wrote:

may be i doesn't understand something but why c#, java, delphi, visual
basic, perl, python, ruby or even ml better than c++?

symbol names in C++ are easily predictable with wrapper using extern
"C". i think that you just not tried to write warppers to code in
other languages - the same problems are everywhere


> Actually, one language you mention there *is* worse than the others
> for writing wrappable library code: C++.  Admittedly, they've got a
> Python interface now via boost, but the main problem with writing
> wrappable C++ code is the template system and the inheritence systems
> getting in the way.  Symbol names aren't predictable and not
> standardized, so it becomes impossible to write a portable system for
> finding and binding to functions in a library.  I've not yet found a
> good way to do it in FFI code, and I would love to, as one library in
> particular I hold near and dear -- OpenSceneGraph -- is entirely
> written in C++.

> -- Jeff

> On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin
> <[EMAIL PROTECTED]> wrote:
>> Hello Mauricio,
>>
>> Tuesday, November 11, 2008, 2:26:21 PM, you wrote:
>>
>> imho, Haskell isn't worse here than any other compiled language - C++,
>> ML, Eiffel and beter tnan Java or C#.every language has its own object
>> model and GC. the only ay is to provide C-typed interfaces between
>> languages (or use COM, IDL and other API-describing languages)
>>
>>> I think Haskell is not nice to write general purpouse libraries
>>> that could be easily and completly wrapped by other languages.
>>> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
>>> python bindings for Data.Graph.
>>
>>> But, then, if you claim there's nothing else Haskell can't do,
>>> what do you need those bindings for ? :)
>>
>>> Best,
>>> Mauricio
>>
 Hi everyone

 So I should clarify I'm not a troll and do "see the Haskell light". But
 one thing I can never answer when preaching to others is "what does
 Haskell not do well?"

 Usually I'll avoid then question and explain that it is a 'complete'
 language and we do have more than enough libraries to make it useful and
 productive. But I'd be keen to know if people have any anecdotes,
 ideally ones which can subsequently be twisted into an argument for
 Haskell ;)

 Cheers,

 Dave
>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>> --
>> Best regards,
>>  Bulatmailto:[EMAIL PROTECTED]
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>






-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Re: What *not* to use Haskell for

[Arnar Birgisson]

On Tue, Nov 11, 2008 at 14:46, Henning Thielemann
<[EMAIL PROTECTED]> wrote:
> SWIG helps wrapping C++ libraries by providing C wrappers to C++ functions.
> However, as far as I know, templates cannot be wrapped as they are, but only
> instances of templates. Thus there is no wrapper to STL.

Maybe my understanding is a bit off, but isn't this to be expected?
There's no way to compile a generic template to machine code, as
template instantiation happens at source level in C++.

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

Re: [Haskell-cafe] Re: What *not* to use Haskell for

[Henning Thielemann]

On Tue, 11 Nov 2008, Jefferson Heard wrote:


Actually, one language you mention there *is* worse than the others
for writing wrappable library code: C++.  Admittedly, they've got a
Python interface now via boost, but the main problem with writing
wrappable C++ code is the template system and the inheritence systems
getting in the way.  Symbol names aren't predictable and not
standardized, so it becomes impossible to write a portable system for
finding and binding to functions in a library.  I've not yet found a
good way to do it in FFI code, and I would love to, as one library in
particular I hold near and dear -- OpenSceneGraph -- is entirely
written in C++.


SWIG helps wrapping C++ libraries by providing C wrappers to C++ 
functions. However, as far as I know, templates cannot be wrapped as they 
are, but only instances of templates. Thus there is no wrapper to STL.


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

Re: [Haskell-cafe] What *not* to use Haskell for

[Arnar Birgisson]

On Tue, Nov 11, 2008 at 14:37, Krasimir Angelov <[EMAIL PROTECTED]> wrote:
> You can hire one Haskell programmer instead of 1,2,3... programmers in
> your favorite imperative language.

That's assuming I can find a Haskell programmer in the first place.
Also, he/she has to be good to replace 10 other programmers.

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Krasimir Angelov]

You can hire one Haskell programmer instead of 1,2,3... programmers in
your favorite imperative language.


On Tue, Nov 11, 2008 at 12:32 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[EMAIL PROTECTED]> wrote:
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>
> I would not use Haskell if I were faced with the prospect of producing
> a huge system in short time (i.e. meaning I couldn't do it by myself)
> and all I had was a pool of "regular" programmers that have been
> trained in .NET, Java, C++, Python,  language>.
>
> Yes, sad - but true. I'd very much like to see this twisted to an
> argument for Haskell :)
>
> cheers,
> Arnar
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What *not* to use Haskell for

[Jefferson Heard]

Actually, one language you mention there *is* worse than the others
for writing wrappable library code: C++.  Admittedly, they've got a
Python interface now via boost, but the main problem with writing
wrappable C++ code is the template system and the inheritence systems
getting in the way.  Symbol names aren't predictable and not
standardized, so it becomes impossible to write a portable system for
finding and binding to functions in a library.  I've not yet found a
good way to do it in FFI code, and I would love to, as one library in
particular I hold near and dear -- OpenSceneGraph -- is entirely
written in C++.

-- Jeff

On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
> Hello Mauricio,
>
> Tuesday, November 11, 2008, 2:26:21 PM, you wrote:
>
> imho, Haskell isn't worse here than any other compiled language - C++,
> ML, Eiffel and beter tnan Java or C#.every language has its own object
> model and GC. the only ay is to provide C-typed interfaces between
> languages (or use COM, IDL and other API-describing languages)
>
>> I think Haskell is not nice to write general purpouse libraries
>> that could be easily and completly wrapped by other languages.
>> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
>> python bindings for Data.Graph.
>
>> But, then, if you claim there's nothing else Haskell can't do,
>> what do you need those bindings for ? :)
>
>> Best,
>> Mauricio
>
>>> Hi everyone
>>>
>>> So I should clarify I'm not a troll and do "see the Haskell light". But
>>> one thing I can never answer when preaching to others is "what does
>>> Haskell not do well?"
>>>
>>> Usually I'll avoid then question and explain that it is a 'complete'
>>> language and we do have more than enough libraries to make it useful and
>>> productive. But I'd be keen to know if people have any anecdotes,
>>> ideally ones which can subsequently be twisted into an argument for
>>> Haskell ;)
>>>
>>> Cheers,
>>>
>>> Dave
>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> --
> Best regards,
>  Bulatmailto:[EMAIL PROTECTED]
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

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

[Haskell-cafe] Re: GHC 6.10 / Mac OS X / Library problem

[Christian Maeder]

Hugo Pacheco wrote:
> it is however. the same happened to me.
> you just need to run
> 
> cabal install pcre-light --extra-include-dirs=/opt/local/include
> --extra-lib-dirs=/opt/local/lib
> 
> My location is /opt/local, since I installed pcre via macports
> 
> sudo port install pcre

Alternatively:
export CPATH=/opt/local/include
export LIBRARY_PATH=/opt/local/lib
export LD_LIBRARY_PATH=/opt/local/lib
export DYLD_LIBRARY_PATH=/opt/local/lib
should work, too

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

[Haskell-cafe] compiling haskell-src-exts in 6.10

[Hugo Pacheco]

When installing package haskell-src-exts via cabal install, I get the error
Language/Haskell/Exts/Syntax.hs:102:7:
Could not find module `Data.Data':
  it is a member of package base, which is hidden


However, when manually installing

runhaskell Setup.hs configure/build/install

It works fine
Somehow package base is not available in cabal.. don't know why.

hugo

-- 
www.di.uminho.pt/~hpacheco
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What *not* to use Haskell for

[Bulat Ziganshin]

Hello Mauricio,

Tuesday, November 11, 2008, 2:26:21 PM, you wrote:

imho, Haskell isn't worse here than any other compiled language - C++,
ML, Eiffel and beter tnan Java or C#.every language has its own object
model and GC. the only ay is to provide C-typed interfaces between
languages (or use COM, IDL and other API-describing languages)

> I think Haskell is not nice to write general purpouse libraries
> that could be easily and completly wrapped by other languages.
> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
> python bindings for Data.Graph.

> But, then, if you claim there's nothing else Haskell can't do,
> what do you need those bindings for ? :)

> Best,
> Mauricio

>> Hi everyone
>> 
>> So I should clarify I'm not a troll and do "see the Haskell light". But
>> one thing I can never answer when preaching to others is "what does
>> Haskell not do well?"
>> 
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>> 
>> Cheers,
>> 
>> Dave

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


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Arnar Birgisson]

Hi all,

On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[EMAIL PROTECTED]> wrote:
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)

I would not use Haskell if I were faced with the prospect of producing
a huge system in short time (i.e. meaning I couldn't do it by myself)
and all I had was a pool of "regular" programmers that have been
trained in .NET, Java, C++, Python, .

Yes, sad - but true. I'd very much like to see this twisted to an
argument for Haskell :)

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

[Haskell-cafe] Re: What *not* to use Haskell for

[Mauricio]

I think Haskell is not nice to write general purpouse libraries
that could be easily and completly wrapped by other languages.
You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
python bindings for Data.Graph.

But, then, if you claim there's nothing else Haskell can't do,
what do you need those bindings for ? :)

Best,
Maurício


Hi everyone

So I should clarify I'm not a troll and do "see the Haskell light". But
one thing I can never answer when preaching to others is "what does
Haskell not do well?"

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful and
productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)

Cheers,

Dave


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

Re: [Haskell-cafe] Exporting a Type Class for Type Signatures

[Malcolm Wallace]

Dominic Steinitz <[EMAIL PROTECTED]> wrote:

> Is there a way of allowing someone to use
> AESKey in a type signature but not allow them to declare new
> instances?

I was going to suggest you export the class abstractly, that is, without
its methods, so no-one could externally create an instance.  But then I
noticed that AESKey has no methods - it is just an alias for a
combination of other classes - so that trick is insufficient.

So, the other thing you could do is to introduce an indirection.

  module This (AESKey) where
class (Bits a, Integral a)  => AESKeyIndirection a  -- un-exported
class (AESKeyIndirection a) => AESKey a -- exported

instance AESKeyIndirection Word128
instance AESKeyIndirection Word192
instance AESKeyIndirection Word256

instance AESKey Word128
instance AESKey Word192
instance AESKey Word256

Creating an instance of AESKey requires that you also create an instance
of AESKeyIndirection.  If only one of the names is available externally
(exported), then instances can only be created internal to the module.

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

Re: [Haskell-cafe] What *not* to use Haskell for

[Jules Bean]

Dave Tapley wrote:

Hi everyone

So I should clarify I'm not a troll and do "see the Haskell light". But
one thing I can never answer when preaching to others is "what does
Haskell not do well?"

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful and
productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)


GHC's scheduler lacks any hard timeliness guarantees.

Thus it's quite hard to use haskell in realtime or even soft-realtime 
environments.


This is probably not a fundamental problem with haskell. It's a problem 
with the compiler/RTS which we happen to be using. It may be true that 
it's harder to write an RTS with realtime guarantees but I doubt it's 
impossible.


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

Re: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell

[José Pedro Magalhães]

Hello Thomas,

I see this is a proposal for a partial implementation of #1673 (
http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be good if
the remaining syntax (associated datatypes and type families) would also be
defined and implemented in TH. Or maybe there isn't much demand for this?...


Cheers,
Pedro

On Wed, Nov 5, 2008 at 15:57, Thomas van Noort <[EMAIL PROTECTED]> wrote:

> Hello,
>
> Recently, we released a library on Hackage for generic rewriting (package
> "rewriting" if you are curious). The user of the library is expected to
> define type class instances to enable rewriting on his or her own datatypes.
> As these instances follow the datatype declarations closely, we tried to
> generate the instances using Template Haskell. Unfortunately, associated
> type synonyms are not yet supported by TH.
>
> After a presentation at the WGP'08, Simon encouraged us to write a proposal
> about adding associated type synonyms to TH, so that it can be added to GHC.
> So, here is our proposal.
>
> The TH AST must allow 1) kind declarations of associated type synonyms
> in class declarations and 2) their definitions in instance declarations.
> For example,
>
> class Foo a where
>  type Bar a :: *
>
> instance Foo Int where
>  type Bar Int = String
>
> The TH library defines a datatype Dec which contains a constructor for
> class declarations and instance declarations:
>
> data Dec
> = ...
> | ClassD Cxt Name [Name] [FunDep] [Dec]
> | InstanceD Cxt Type [Dec]
>  ...
>
> 1) Associated type synonym kind declarations
>
> We suggest to add a constructor to the Dec type:
>
>  ...
> | AssocTySynKindD Name [Name] (Maybe Kind)
>  ...
>
> assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ
>
> The first field is the name of the associated type synonym, the second
> field is a list of type variables, and the third field is an optional kind.
> Since kinds are not yet defined in TH, we have to add some kind of kind
> definition (pun intended):
>
> data Kind
> = StarK
> | ArrowK Kind Kind
>
> type KindQ = Q Kind
> starK :: KindQ
> arrowK :: KindQ -> KindQ -> KindQ
>
> We explicitly choose not to reuse the Type type to define kinds (i.e., type
> Kind = Type as in GHC) since we think a separation between the two worlds is
> much clearer to the users of TH.
>
> 2) Associated type synonym definitions
>
> We suggest to add another constructor to the Dec type:
>
>  ...
> | AssocTySynD Name [Type] Type
>  ...
>
> assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ
>
> The first field is the name of the type synonym, the second field is a list
> of type arguments, and the third field is the body of the type synonym.
>
> We would like to hear your comments to this proposal.
>
> Regards,
> Thomas
> ___
> 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] What *not* to use Haskell for

[Dave Tapley]

Hi everyone

So I should clarify I'm not a troll and do "see the Haskell light". But
one thing I can never answer when preaching to others is "what does
Haskell not do well?"

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful and
productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)

Cheers,

Dave

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

Re: [Haskell-cafe] Re: download haskell?

[Thomas Schilling]

2008/11/11 Benjamin L. Russell <[EMAIL PROTECTED]>:

> Haskell's corresponding link should probably be (somewhat
> facetiously):
>
> download ::  Click -> HaskellCompiler
> download GHC

parse error (possibly incorrect indentation)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: reliable (bi)directional pipe to a process

[Johannes Waldmann]

> I too have noticed insidious bugs in GHC run-time when communicating
> with another process via a pipe. I tried to use runInteractiveProcess;
> it worked -- up to file sizes of about 300Kb.

Yeah, I seem to be running into similar strange problems,
so I'll be definitely checking out your code.

(Why didn't I file bug reports? Because I couldn't isolate
the problem well, so my whole setup including external programs
would have to be duplicated, and I don't expect GHC headquarters to 
be willing to do this. No complaints.)

J.W.

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

Re: [Haskell-cafe] GHC 6.10, strange behaviour when profiling?

[Thomas Schilling]

I think you hit bug http://hackage.haskell.org/trac/ghc/ticket/2747,
which is an accounting bug in the garbage collector and goes away when
you trigger more garbage collections (which -hc does, I think).
Please file a bug report anyway, so we can verify that it is indeed
not a new bug.  (Since the profiler modifies the program it can turn
on or off different optimisations, so it's quite possible that there
are other reasons for this behaviour.)


2008/11/10 Aleš Bizjak <[EMAIL PROTECTED]>:
> Hello,
>
> I'm experiencing some strange behaviour with GHC 6.10 and would like an
> explanation why.
>
> Here's the problem. With GHC 6.8.[23] memory usage of a program was about
> 250mb (computing pi to 10^6 decimals).
> Now I tried recompiling and running with GHC 6.10 and I got more than 1.4gb
> before I killed it, so naturally I tried profiling but
> here's the strangeness. When I compile for profiling with -prof -auto-all
> and run with +RTS -p -RTS memory use is
> still about the same as before (> 1.4gb), but when I try running with +RTS
> -hc -RTS memory only reaches about 250mb.
>
> What is the explanation for this behaviour?
>
> I would send a program but it requires HERA, which is not on hackage ...
>
> Here is the output of -s
>
> ./Test 10 +RTS -s
>  47,467,176 bytes allocated in the heap
>  18,046,776 bytes copied during GC
>   9,215,104 bytes maximum residency (6 sample(s))
> 711,520 bytes maximum slop
>  80 MB total memory in use (11 MB lost due to fragmentation)
>
>  Generation 0:84 collections, 0 parallel,  0.01s,  0.01s elapsed
>  Generation 1: 6 collections, 0 parallel,  0.01s,  0.01s elapsed
>
>  INIT  time0.00s  (  0.00s elapsed)
>  MUT   time3.66s  (  3.71s elapsed)
>  GCtime0.02s  (  0.02s elapsed)
>  RPtime0.00s  (  0.00s elapsed)
>  PROF  time0.00s  (  0.00s elapsed)
>  EXIT  time0.00s  (  0.00s elapsed)
>  Total time3.68s  (  3.73s elapsed)
>
>  %GC time   0.5%  (0.6% elapsed)
>
>  Alloc rate12,982,553 bytes per MUT second
>
>  Productivity  99.5% of total user, 97.9% of total elapsed
>
>
>
>
> ./Test 10 +RTS -s -hc
>  47,471,160 bytes allocated in the heap
>  18,637,752 bytes copied during GC
>  13,580,144 bytes maximum residency (37 sample(s))
> 810,712 bytes maximum slop
>  33 MB total memory in use (7 MB lost due to fragmentation)
>
>  Generation 0:85 collections, 0 parallel,  0.02s,  0.02s elapsed
>  Generation 1:37 collections, 0 parallel,  0.00s,  0.01s elapsed
>
>  INIT  time0.00s  (  0.00s elapsed)
>  MUT   time3.67s  (  3.73s elapsed)
>  GCtime0.02s  (  0.03s elapsed)
>  RPtime0.00s  (  0.00s elapsed)
>  PROF  time0.00s  (  0.00s elapsed)
>  EXIT  time0.00s  (  0.00s elapsed)
>  Total time3.70s  (  3.77s elapsed)
>
>  %GC time   0.6%  (0.8% elapsed)
>
>  Alloc rate12,941,165 bytes per MUT second
>
>  Productivity  99.2% of total user, 97.4% of total elapsed
>
>
>
>
> --
> Best regards, Aleš
> ___
> 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: reliable (bi)directional pipe to a process

[Jason Dusek]

  There is actually a real wealth of material on generalizing
  I/O on your site -- it's definitely something I will be ever
  more interested in.

  Now that I think about it, I can remember a time where a
  program that did a lot of stuff with Amazon would mysteriously
  run out of file descriptors, and I just had to put some shell
  around it to kick it over and over again.

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

Re: [Haskell-cafe] Histogram creation

[Ketil Malde]

Duncan Coutts <[EMAIL PROTECTED]> writes:

> Perhaps I misunderstood but I think Alexey means that he wants to
> accumulate several different histograms (ie different arrays) but to
> only make one pass over the input data. 

This is precicely my problem, too.

> The form of accumArray does not make that possible (unless one
> managed to pack the different histograms into different parts of the
> same array). 

This would have been a good match for my case.

Of course, that is a bit of a hack, and it would be much nicer and
safer to do an accumArray with tuple elements.  But I need to use an
UArray in order to avoid the array filling up with unevaluated thunks,
and - correct me if I'm wrong - there's no way to do a 'seq' before
accumArray's insertion for complex types.  So the stack blows up.

/me wishes for s/Data.Array.Unboxed/Data.Array.Strict/g and instances
for arbitrary types.

Anyway, I thought of using offsets in the same UArray too late, and
chose to finish my ST-based implementation instead. 

> If a fold using a pure persistent map type really is too slow then it
> should still be possible to do an ST implementation in a reasonably
> elegant way using a foldr on the input list, accumulating an ST action. 

Or must mapM_ an insert operation (in ST) over the input data?

-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