4 ms·

It is true that Haskell is about denotational safety (correctness) not operational safety (performance limits). You do not need IO limitations for logging. You

by judk 13y ago

It is true that Haskell is about denotational safety (correctness) not operational safety (performance limits). You do not need IO limitations for logging. You can use Debug.Trace Haskell does have a heap analyzer. Like C, you can choose to compiler an instrumented binary with debug symbols. There are a huge suite of tools coming around this year. Debugging and analysis has been a huge theme recently. Simon Marlow's recent book gives a taste, as does the latest Communities And Activities Report.

tene 13y ago
The book mentioned seems to be "Parallel And Concurrent Programming In Haskell", available online here: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929
pekk 13y ago
How is a program correct if resource leaks cause it not to perform the intended task?
- axman6 13y ago
  I think this is more of an implementation issue than a language issue. A haskell compiler could choose to reevaluate everything every time it's demanded, and it would run in very little space. GHC uses thunks to represent computations which haven't been run yet, which are replaced once any threads evaluates them. This can lead to space leaks, but I don't believe there's any requirement that this be how the results are evaluated. GHC chooses this evaluation strtategy because it usually results in faster code, but obviously can lead to problems if you don't know what you're doing. Like all languages, it takes experience to avoid whatever deficiency exists in your language of choice; it won't be obvious to a beginner why the naive implementation of fibonacci works for some values but overflows the stack on others, but they will eventually learn.
- chongli 13y ago
  Haskell the language is concerned with proving small theorems about the program as specified by the source code. Actually running it is outside the scope of language specification; it's an implementation detail. GHC (the defacto compiler for Haskell) makes a lot of resource tradeoffs to try and achieve better performance.

by judk 13y ago

tene 13y ago

The book mentioned seems to be "Parallel And Concurrent Programming In Haskell", available online here: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929

pekk 13y ago

How is a program correct if resource leaks cause it not to perform the intended task?

axman6 13y ago
I think this is more of an implementation issue than a language issue. A haskell compiler could choose to reevaluate everything every time it's demanded, and it would run in very little space. GHC uses thunks to represent computations which haven't been run yet, which are replaced once any threads evaluates them. This can lead to space leaks, but I don't believe there's any requirement that this be how the results are evaluated. GHC chooses this evaluation strtategy because it usually results in faster code, but obviously can lead to problems if you don't know what you're doing. Like all languages, it takes experience to avoid whatever deficiency exists in your language of choice; it won't be obvious to a beginner why the naive implementation of fibonacci works for some values but overflows the stack on others, but they will eventually learn.
chongli 13y ago
Haskell the language is concerned with proving small theorems about the program as specified by the source code. Actually running it is outside the scope of language specification; it's an implementation detail. GHC (the defacto compiler for Haskell) makes a lot of resource tradeoffs to try and achieve better performance.