Lo guys,
I thought you'd like to know about this result. I've been playing
with the debian language shootout programs under OS X, looking at how
fast Haskell code is compared to C on OS X, rather than linux.
Interestingly, Haskell comes out rather better on OS X than it did on
Linux.
Piyush P Kurur wrote:
( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 )
I am planing a haskell based functional programming course.
It is supposed to be a first course and I intend to show how
real world applications can be built quite easily in haskell.
Any feed back
On Fri, Aug 22, 2008 at 1:46 PM, Daryoush Mehrtash [EMAIL PROTECTED] wrote:
Are the book's sample code available for download?
Not yet.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hey all,
I was playing around with type families, and I have a strange problem.
Suppose we have an alternative to an Either datatype:
data (:|:) a b = Inl a | Inr b
and a class Ix:
class Ix i where
type IxMap i :: * - *
empty :: IxMap i [Int]
Now I want to give an instance for (a
2008/8/23 Thomas Davie [EMAIL PROTECTED]:
Finally, that threading example... WOW! 65 times faster, and the code is
*really* simple. The C on the other hand is a massive mess.
I've been wondering about this, but I can't check because I don't have
a multi core cpu. I've heard GHC's single
On Sat, Aug 23, 2008 at 7:55 AM, Chris Eidhof [EMAIL PROTECTED] wrote:
Hey all,
I was playing around with type families, and I have a strange problem.
Suppose we have an alternative to an Either datatype:
data (:|:) a b = Inl a | Inr b
and a class Ix:
class Ix i where
type IxMap i ::
On 23 Aug 2008, at 20:01, Luke Palmer wrote:
2008/8/23 Thomas Davie [EMAIL PROTECTED]:
Finally, that threading example... WOW! 65 times faster, and the
code is
*really* simple. The C on the other hand is a massive mess.
I've been wondering about this, but I can't check because I don't
Today I made an interesting discovery.
We all know the benefits of a strong type system, and often tout it as
a major advantage of using Haskell. The discovery I made, was that C
programmer don't realise the implications of that, as this comment
highlights:
It seems to me we should condense this thread into a series of new
entires on the Haskell in Education page?
People seem to be doing new courses, and new kinds of courses, in
Haskell, so reflecting that online is a good idea.
http://haskell.org/haskellwiki/Haskell_in_education
waldmann:
On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote:
Today I made an interesting discovery.
We all know the benefits of a strong type system, and often tout it as
a major advantage of using Haskell. The discovery I made, was that C
programmer don't realise the implications of that, as
On 23 Aug 2008, at 22:36, Matus Tejiscak wrote:
On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote:
Today I made an interesting discovery.
We all know the benefits of a strong type system, and often tout it
as
a major advantage of using Haskell. The discovery I made, was that C
I guess I didn't express my point very clearly... That C programmers
apparently don't realise that a type system that's sound will give them
something -- i.e. their programmer won't ever segfault. I wonder when we try
to advertise Haskell if we should be saying we can give you programs that
newsham:
I guess I didn't express my point very clearly... That C programmers
apparently don't realise that a type system that's sound will give them
something -- i.e. their programmer won't ever segfault. I wonder when we
try to advertise Haskell if we should be saying we can give you
On 23 Aug 2008, at 23:10, Tim Newsham wrote:
I guess I didn't express my point very clearly... That C
programmers apparently don't realise that a type system that's
sound will give them something -- i.e. their programmer won't ever
segfault. I wonder when we try to advertise Haskell if
On 23 Aug 2008, at 23:10, Tim Newsham wrote:
I guess I didn't express my point very clearly... That C
programmers apparently don't realise that a type system that's
sound will give them something -- i.e. their programmer won't ever
segfault. I wonder when we try to advertise Haskell if
I guess I didn't express my point very clearly... That C programmers
apparently don't realise that a type system that's sound will give
them something -- i.e. their programmer won't ever segfault. I wonder
when we try to advertise Haskell if we should be saying we can give
you programs that
As a day-time java programmer, I can say from experience that sometimes (100%
pure) Java programs DO segfault.
I've had it happen to me, and while you can justifiably say it's an error in
the JVM somehow triggered by your program behaviour/timing, that doesn't help
you very much at the time.
On 2008 Aug 23, at 18:34, Krzysztof Skrzętnicki wrote:
Recently I wrote computation intensive program that could easily
utilize both cores. However, there was overhead just from compiling
with -threaded and making some forkIO's. Still, the overhead was not
larger than 50% and with 4 cores I
Thomas Davie wrote:
http://games.slashdot.org/comments.pl?sid=654821cid=24716845
Apparently, no one realises that a SEGFAULT is a type error, just not
a very helpful one.
Right, so here's an action plan for a clueless C-programmer:
- Recompile program in debug mode.
- Start application in
On 2008 Aug 23, at 17:29, C.M.Brown wrote:
I wonder whether seg faults are the true analogue to errors such as
error: head empty list. or pattern match errors.
Not really; while laziness does introduce a certain amount of spooky
action at a difference to such errors, it's not nearly as bad
I'm writing an NNTP client API. When I connect with connectTo, I get a
Handle 'h'. I immediately hGetContents h to get a string 'c' that I
hope contains all the data the server will ever send. I put h and c in
a data Connection and pass it to the functions that send or receive.
I send a command
brian wrote:
Here's an error the Haskell run-time system might throw:
*** Exception: Prelude.head: empty list
(or whatever)
So now what? Action plan = [].
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14
Thank you for the URL, but I'm aware of the work in GHC(i). As I've
mentioned
wrt head [], Niels said:
So now what? Action plan = []
Oh come now. Between ghci, hpc, and manual analysis I've never hit a
Haskell error and thrown my hands up, I can't go any further, I'm at a
complete loss! Also it helps that I run into this extremely rarely - I
have a larger habit of
G'day all.
Quoting Don Stewart [EMAIL PROTECTED]:
We promise both safety and efficiency.
We also provide (though don't promise) modularity, robustness
and correctness, which is not something that Java gives you out
of the box.
Cheers,
Andrew Bromage
That's really interesting -- I just tried this.
Compiling not using -threaded: 1.289 seconds
Compiling using -threaded, but not running with -N2: 3.403 seconds
Compiling using -threaded, and using -N2: 55.072 seconds
I was hoping to see a relative improvement when introducting an
Thank you Murray. My post was not so clear I was referring to
automatic parellelization vs manual parallelization. By automatic I
mean the programmer doesn't have to indicate where to parallelize ...
instead the compiler decides how to parallize!
Vasili
On Sat, Aug 23, 2008 at 12:58 AM,
On 2008.08.24 01:29:18 +0200, Niels Aan de Brugh [EMAIL PROTECTED] scribbled
1.0K characters:
Thomas Davie wrote:
http://games.slashdot.org/comments.pl?sid=654821cid=24716845
Apparently, no one realises that a SEGFAULT is a type error, just not
a very helpful one.
Right, so here's an action
27 matches
Mail list logo
