[Haskell-cafe] Problem on overlapping instances

[Magicloud Magiclouds]

Hi,
  I am using Data.Binary which defined "instance Binary a => Binary
[a]". Now I need to define "instance Binary [String]" to make
something special for string list.
  How to make it work? I looked into the chapter of
overlappinginstances, nothing works.
-- 
竹密岂妨流水过
山高哪阻野云飞

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

Re: [Haskell-cafe] Problem on overlapping instances

[Steffen Schuldenzucker]

Am 05.01.2011 09:24, schrieb Magicloud Magiclouds:

Hi,
   I am using Data.Binary which defined "instance Binary a =>  Binary
[a]". Now I need to define "instance Binary [String]" to make
something special for string list.
   How to make it work? I looked into the chapter of
overlappinginstances, nothing works.


Just a guess: Have you enabled TypeSynonymInstances? (As String is a 
type synonym, at least this extension would be required)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem on overlapping instances

[Jasper Van der Jeugt]

Hello,

{-# LANGUAGE OverlappingInstances, FlexibleInstances #-}
import Data.Binary

instance Binary [String] where
get = undefined
put = undefined

works fine here on GHC 6.12.3. That being said, it would be safer
perhaps to add a newtype around [String] so you can avoid the orphan
instance as well, i.e.

import Data.Binary

newtype MyType = MyType [String]

instance Binary MyType where
get = undefined
put = undefined

Cheers,
Jasper

On Wed, Jan 5, 2011 at 9:24 AM, Magicloud Magiclouds
 wrote:
> Hi,
>  I am using Data.Binary which defined "instance Binary a => Binary
> [a]". Now I need to define "instance Binary [String]" to make
> something special for string list.
>  How to make it work? I looked into the chapter of
> overlappinginstances, nothing works.
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
>
> ___
> 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] Problem on overlapping instances

[Luke Palmer]

You can't.  If you have special semantics for [String], then it is not
really a [String], it is something else.  So let the type system know
that:

newtype SomethingElse = SomethingElse [String]

instance Binary SomethingElse where
...

On Wed, Jan 5, 2011 at 1:24 AM, Magicloud Magiclouds
 wrote:
> Hi,
>  I am using Data.Binary which defined "instance Binary a => Binary
> [a]". Now I need to define "instance Binary [String]" to make
> something special for string list.
>  How to make it work? I looked into the chapter of
> overlappinginstances, nothing works.
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
>
> ___
> 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] Problem on overlapping instances

[Stephen Tetley]

You have two choices (other people have enumerated the first while I
was typing):

First choice:

Wrap your Stringlist with a newtype:

newtype StringList = StringList [String]

The downside of this your code gets "polluted" with the newtype.

Second choice:

Write special putStringList and getStringList functions. Hand-code the
binary instances where you are wanting [String] to be special and call
putStringList and getStringList rather than put and get.

Downside - cannot automatically derive Binary. That's if Binary can be
automatically derived anyway?, the times when I need Binary I write
the instances myself anyway.

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

[Haskell-cafe] Network.Curl and thread safety

[Iustin Pop]

Hi all,

I'm not able to find out how one can use Network.Curl with the
threaded runtime safely.

I have this simple example:

import Network.Curl
import Control.Concurrent
import Control.Concurrent.MVar

getUrl :: (Monad m) => String -> IO (m String)
getUrl url = do
  (code, body) <- curlGetString url [CurlSSLVerifyPeer False,
 CurlSSLVerifyHost 0,
 CurlTimeout 15,
 CurlConnectTimeout 5]
  return $ case code of
 CurlOK -> return body
 _ -> fail $ "Curl error for " ++ url ++ " error " ++ show code

runGet :: String -> MVar (Maybe String) -> IO ()
runGet url mv = do
  body <- getUrl url
  putMVar mv body

main = withCurlDo $ do
  let urls = replicate 10 "https://google.com/";
  mvs <- mapM (\_ -> newEmptyMVar) urls
  mapM_ (\(mv, url) -> forkIO (runGet url mv)) $ zip mvs urls
  mapM (\mv -> takeMVar mv >>= print) mvs
  threadDelay 1000


When using curl linked with GnuTLS and running it with the
multi-threaded runtime, it fails immediately with:
  $ ./main 
  main: ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock ==
  ((ath_mutex_t) 0)' failed.
  Aborted (core dumped)

Reading the Network.Curl docs, it seems that using withCurlDo should be
enough to make this work (although I'm not sure about the description of
the function and "no forking or lazy returns").

Using Network.Curl built against the OpenSSL headers does successfully
retrieve all URLs, but fails a bit later (during the threadDelay,
probably in GC) again with segmentation fault in libcurl.4.so.

I've tried changing forkIO to forkOS, but still no luck, with either SSL
library.

Any ideas what I'm doing wrong?

regards,
iustin

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

[Haskell-cafe] Type System vs Test Driven Development

[Jonathan Geddes]

Cafe,

In every language I program in, I try to be as disciplined as possible
and use Test-Driven Development. That is, every language except
Haskell.

There are a few great benefits that come from having a comprehensive
test suite with your application:

1. Refactoring is safer/easier
2. You have higher confidence in your code
3. You have a sort of 'beacon' to show where code breakage occurs

Admittedly, I don't believe there is any magical benefit that comes
from writing your tests before your code. But I find that when I don't
write tests first, it is incredibly hard to go back and write them for
'completed' code.

But as mentioned, I don't write unit tests in Haskell. Here's why not.

When I write Haskell code, I write functions (and monadic actions)
that are either a) so trivial that writing any kind of unit/property
test seems silly, or are b) composed of other trivial functions using
equally-trivial combinators.

So, am I missing the benefits of TDD in my Haskell code?

Is the refactoring I do in Haskell less safe? I don't think so. I
would assert that there is no such thing as refactoring with the style
of Haskell I described: the code is already super-factored, so any
code reorganization would be better described as "recomposition." When
"recomposing" a program, its incredibly rare for the type system to
miss an introduced error, in my experience.

Am I less confidence in my Haskell code? On the contrary. In general,
I feel more confident in Haskell code WITHOUT unit tests than code in
other languages WITH unit tests!

Finally, am I missing the "error beacon" when things break? Again I
feel like the type system has got me covered here. One of the things
that immediately appealed to me about Haskell is that the strong type
system gives the feeling of writing code against a solid test base.

The irony is that the type system (specifically the IO monad) force
you to structure code that would be very easy to test because logic
code is generally separated from IO code.

I explained these thoughts to a fellow programmer who is not familiar
with Haskell and his response was essentially that any language that
discourages you from writing unit tests is a very poor language. He
(mis)quoted: "compilation [is] the weakest form of unit testing" [0].
I vehemently disagreed, stating that invariants embedded in the type
system are stronger than any other form of assuring correctness I know
of.

I know that much of my code could benefit from a property test or two
on the more complex parts, but other than that I can't think that unit
testing will improve my Haskell code/programming practice. Am I
putting too much faith in the type system?

[0] http://blog.jayfields.com/2008/02/static-typing-considered-harmful.html

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Erik de Castro Lopo]

Jonathan Geddes wrote:



> So, am I missing the benefits of TDD in my Haskell code?

Probably. I work on a project which has 4+ lines of
haskell code (a compiler written in haskell) and has a huge
test suite that is a vital to continued development.

I've also written relatively small functions (eg a function
to find if a graph has cycles) that was wrong first time I
wrote it. During debugging I wrote a test that I'm keeping
as part of the unit tests. 

Furthermore tests are also useful for preventing regressions
(something the programmer is doing today, breaks something
that was working 6 months ago). Without tests, that breakage
may go un-noticed.

> I explained these thoughts to a fellow programmer who is not familiar
> with Haskell and his response was essentially that any language that
> discourages you from writing unit tests is a very poor language.

Haskell most certainly does not discourage anyone from writing
tests. One simply needs to look at the testing category of
hackage:

http://hackage.haskell.org/package/#cat:testing

to find 36 packages for doing testing.

> Am I putting too much faith in the type system?

Probably.

> [0] http://blog.jayfields.com/2008/02/static-typing-considered-harmful.html

Complete bollocks!

Good type systems combined with good testing leads to better
code than either good type systems or good testing alone.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

[Haskell-cafe] [ANNOUNCE] Etage 0.1.7, a general data-flow framework

[Mitar]

Hi!

I am glad to announce a new version of Etage, a general data-flow
framework. Now it supports also GHC 7.0 and not just GHC head and
because of this also Hackage successfully generates documentation so
it is easier to understand the framework.

http://hackage.haskell.org/package/Etage

Feel free to test it and provide any feedback


Mitar

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

Re: [Haskell-cafe] Problem on overlapping instances

[Magicloud Magiclouds]

Steffen Schuldenzucker:
  Sure. GHC would prompt that.

Jasper Van der Jeugt:
  Not working with ghc7. But there sure are some threads about this
kind of things. I do not know if this is a bug of 6.* or 7, either.

Luke Palmer:
  Sorry, by special, I meant, for example, ["a", "b"] will be "ab" by
default, but I want it to be "a,b". So I'd like to overload for
certain types.

Stephen Tetley:
  I think that are the only choices. The first is simple, but the
second saves some code writing.

After all, thanks.

On Wed, Jan 5, 2011 at 4:41 PM, Stephen Tetley  wrote:
> You have two choices (other people have enumerated the first while I
> was typing):
>
> First choice:
>
> Wrap your Stringlist with a newtype:
>
> newtype StringList = StringList [String]
>
> The downside of this your code gets "polluted" with the newtype.
>
> Second choice:
>
> Write special putStringList and getStringList functions. Hand-code the
> binary instances where you are wanting [String] to be special and call
> putStringList and getStringList rather than put and get.
>
> Downside - cannot automatically derive Binary. That's if Binary can be
> automatically derived anyway?, the times when I need Binary I write
> the instances myself anyway.
>
> ___
> 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] Type System vs Test Driven Development

[Sönke Hahn]

Erik de Castro Lopo wrote:

> Jonathan Geddes wrote:
> 
> 
> 
>> So, am I missing the benefits of TDD in my Haskell code?
> 
> Probably. I work on a project which has 4+ lines of
> haskell code (a compiler written in haskell) and has a huge
> test suite that is a vital to continued development.



If I may, I would like to agree with you both: A test suite should ideally 
cover all the aspects of the tested program, that are not checked statically 
by the compiler. So in python, I end up writing test cases that check for 
runtime type errors; in haskell, I don't. In both languages, it's good 
advice to write a test suite that checks the correctness of calculated 
values.

Haskell's static type system feels to me like an automatically generated, 
somehow dumb test suite. It does not replace a full-flegded hand-written 
one, but it does replace a big part of it (that is, of what you would have 
to write in a dynamic language). And it runs much faster.

I also tend to write test suites when I feel, the code exceeds a certain 
level of complexity. This level is language dependent and in haskell's case, 
it's pretty high. (I should probably lower that level and write more test 
cases, but that seems to be true for all languages.)

And yes, haskell has great support for writing test suites.



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

Re: [Haskell-cafe] Odd profiling results

[Simon Marlow]

On 04/01/2011 21:20, Erik de Castro Lopo wrote:

Malcolm Wallace wrote:


The peaks I am guessing are largely attributable to parsing the source
files.  Then, once the source has been converted to an AST, the DDC
compiler is presumably doing some analysis before moving on to the
next file?  I think these are the well-behaved flat bits.  These
phases do not allocate anything fresh, so they are not creating new
data-structures, but perhaps are propagating static information around
the AST. Something like a type/effect analysis maybe?


Thanks Malcolm, I think you may indeed be correct.

It should also be pretty easy to test that hypothesis and that is
my next task.


Or the C compiler, perhaps?

Cheers,
Simon

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

Re: [Haskell-cafe] thread safety, IO arrays, and IO refs

[Simon Marlow]

On 31/12/2010 09:19, Eric Stansifer wrote:

Hello,

I wish to use a mutable array in multiple threads.  Can IO arrays be
used in any thread, or only the thread they are created in?  (So if I
create an IO array in one thread, pass it to another via an MVar, can
I read / edit it in that other thread?)  Similarly about IORefs... can
they be used across threads?


There are no restrictions, you can use an IOArray or IORef in any thread.

Cheers,
Simon

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

[Haskell-cafe] Choosing a type-class instance based on the context

[Cristiano Paris]

Hi all,

I was reading:

http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap

and I became curious. Playing with the code I started to find a way to say:

instance Show a => ShowPred a HTrue

instead of enumerating all the instances, mirroring those of the Show class:

instance ShowPred Int  HTrue
instance ShowPred Bool HTrue
instance ShowPred a flag => ShowPred [a] flag

Would that be possible? My opinion is that's not possible but I want
to hear what the type-system gurus think about it.

Thanks,

-- 
Cristiano

GPG Key: 4096R/C17E53C6 2010-02-22
Fingerprint = 4575 4FB5 DC8E 7641 D3D8  8EBE DF59 B4E9 C17E 53C6

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Jake McArthur]

On 01/05/2011 03:44 AM, Jonathan Geddes wrote:

When I write Haskell code, I write functions (and monadic actions)
that are either a) so trivial that writing any kind of unit/property
test seems silly, or are b) composed of other trivial functions using
equally-trivial combinators.


"There are two ways of constructing a software design. One way is to 
make it so simple that there are obviously no deficiencies. And the 
other way is to make it so complicated that there are no obvious 
deficiencies." -- C.A.R. Hoare


If you actually manage to do the former, I'd say you don't need to test 
those parts in isolation.


That said, I disagree with you overall. The Haskell type system is 
simply not rich enough to guarantee everything you might need. Even if 
it was, it would take a lot of work to encode all your invariants, 
probably more work than writing tests would have been (although there 
are obvious advantages to the former as far as having a high level of 
assurance that your code is correct).


Haskell has some awesome testing tool, and I highly recommend getting 
acquainted with them. In particular, you should definitely learn how to 
use QuickCheck, which allows you to easily check high-level properties 
about your code; this is beyond what most traditional unit tests could 
hope to achieve. I tend to use QuickCheck, SmallCheck, *and* 
LazySmallCheck in my test suites, as I feel that they complement each 
other well. HUnit is probably the main one for traditional unit tests. I 
admit I have never used it, and I'm not sure whether I'm missing out on 
anything. There are also some pretty nice test frameworks out there to 
help you manage all your tests, although they could probably use a 
little more work overall.


- Jake

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

Re: [Haskell-cafe] Misleading MVar documentation

[Bertram Felgenhauer]

Mitar wrote:
> Hi!
> 
> On Sat, Dec 25, 2010 at 11:58 AM, Edward Z. Yang  wrote:
> > I think you're right. A further comment is that you don't really need
> > stringent timing conditions (which is the only thing I think of when
> > I hear "race") to see another thread "grab" the mvar underneath
> > you
> 
> Yes, MVars are (bounded, 1 space long) queues with predictable behavior.
> 
> Maybe we should change documentation for swapMVar (and others) and
> replace notion of race condition with that it can block.

But this was not the issue this thread was about, namely: If readMVar
(to pick one example) is applied to a full MVar with a pending putMVar,
then readMVar will block *after* reading the value from the MVar,
before being able to put it back. This is surprising, as it means that
the value of the MVar can change during the execution of readMVar. (it
will be changed back before readMVar completes but then the damage may
already be done.)

I think atomicity is the right concept here: All these operations consist
of two separate steps (and can be interrupted in the middle) and this
behaviour is observable if the MVar is not used in a single token mutex
fashion, where either the MVar is full or there is exactly one thread
owning the token. (Unlike simple mutexes, the MVar token can be labeled
and re-labeled by the thread owning it.)

Best regards,

Bertram

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

[Haskell-cafe] Experiences with Intel's manycore lab?

[Michael Lesniak]

Hello,

does anyone have experiences (good/bad) or some good-to-know knowledge
about Intel's manycore lab, which supposedly has GHC 6.13
installed[1]?

Regards,
  Michael

[1] 
http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

-- 
Dipl.-Inf. Michael C. Lesniak
University of Kassel
Programming Languages / Methodologies Research Group
Department of Computer Science and Electrical Engineering

Wilhelmshöher Allee 73
34121 Kassel

Phone: +49-(0)561-804-6269

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

Re: [Haskell-cafe] UTF-8 BOM

[Gregory Collins]

Use the text library instead?

On Jan 5, 2011 2:09 AM, "Tony Morris"  wrote:
>
> I am reading files with System.IO.readFile. Some of these files start
> with a UTF-8 Byte Order Marker (0xef 0xbb 0xbf). For some functions that
> process this String, this causes choking so I drop the BOM as shown
> below. This feels particularly hacky, but I am not in control of many of
> these functions (that perhaps could use ByteString with a better
solution).
>
> I'm wondering if there is a better way of achieving this goal. Thanks
> for any tips.
>
>
> dropBOM ::
>  String
>  -> String
> dropBOM [] =
>  []
> dropBOM s@(x:xs) =
>  let unicodeMarker = '\65279' -- UTF-8 BOM
>  in if x == unicodeMarker then xs else s
>
> readBOMFile ::
>  FilePath
>  -> IO String
> readBOMFile p =
>  dropBOM `fmap` readFile p
>
>
>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
> ___
> 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] Trouble installing FileManipCompat

[Tony Miller]

Thanks that works, but I have packages that rely on mtl>=2.0, so its
not the best solution. Perhaps the maintainer of FileManipCompat could
be contacted to update the package?

On 1/4/11, Daniel Fischer  wrote:
> On Wednesday 05 January 2011 01:54:36, Tony Miller wrote:
>> Hi,
>>
>> I'm trying to install FileManipCompat(well, really
>> HStringTemplateHelpers, but the error is from FileManipCompat) and I'm
>> getting this error:
>>
>> [1 of 1] Compiling System.FilePath.FindCompat (
>> System/FilePath/FindCompat.hs, dist/build/System/FilePath/FindCompat.o
>> )
>>
>> System/FilePath/FindCompat.hs:175:20:
>> Not in scope: data constructor `State'
>
> Apparently the code is written for an older version of mtl.
> As of mtl-2.*, State is no longer a separate type, it's a type synonym for
>
> StateT s Identity
>
> now.
>
> You can try
>
> $ cabal install --constraint="mtl < 2.0" HStringTemplateHelpers
>
> (although having multiple versions of mtl installed may lead to some
> headaches too).
>
>
>

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

Re: [Haskell-cafe] Trouble installing FileManipCompat

[Daniel Fischer]

On Wednesday 05 January 2011 19:43:53, Tony Miller wrote:
> Thanks that works, but I have packages that rely on mtl>=2.0, so its
> not the best solution. Perhaps the maintainer of FileManipCompat could
> be contacted to update the package?

Visiting http://hackage.haskell.org/package/FileManip reveals that that 
package is obsolete, one should use filemanip (all lowercase) instead, 
which has been built on 6.12 and 7.0, so that should work and it's rather 
the maintainer(s) of HStringTemplateHelpers (and FileManipCompat) who 
should be asked to update their package(s).

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

Re: [Haskell-cafe] Choosing a type-class instance based on the context

[Stephen Tetley]

Though its quite different to AdvancedOverlap, Conal Elliott has a
method of answering the title of your post - "Choosing a type-class
instance based on the context".

See the CxMonoid (context monoid) in Section 3. Flexible Layout of the
paper Applicative Data-Driven Computation.

http://conal.net/papers/data-driven/paper.pdf

Best wishes

Stephen

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Jonathan Geddes]

> The Haskell type system is simply not rich enough to guarantee everything you 
> might need.

That's true, and after giving this a bit more thought, I realized it's
not JUST the type system that I'm talking about here. There are a few
other features that make it hard for me to want to use unit/property
tests.

For example, say (for the sake of simplicity and familiarity) that I'm
writing the foldl function. If I were writing this function in any
other language, this would be my process: first I'd write a test to
check that foldl returns the original accumulator when the list is
empty. Then I would write code until the test passed. Then I would
move on to the next property of foldl and write a test for it. Rinse
repeat.

But in Haskell, I would just write the code:

> foldl _ acc [] = acc

The function is obviously correct for my (missing) test. So I move on
to the next parts of the function:

>foldl _ acc [] = acc
>foldl f acc (x:xs) = foldl f (f acc x) xs

and this is equally obviously correct. I can't think of a test that
would increase my confidence in this code. I might drop into the ghci
repl to manually test it once, but not a full unit test.

I said that writing Haskell code feels like "writing code against a
solid test base." But I think there's more to it than this. Writing
Haskell code feels like writing unit tests and letting the machine
generate the actual code from those tests. Declarative code for the
win.

Despite all this, I suspect that since Haskell is at a higher level of
abstraction than other languages, the tests in Haskell must be at a
correspondingly higher level than the tests in other languages. I can
see that such tests would give great benefits to the development
process. I am convinced that I should try to write such tests. But I
still think that Haskell makes a huge class of tests unnecessary.

> Haskell has some awesome testing tool, and I highly recommend getting
> acquainted with them.

I will certainly take your advice here. Like I said, I use TDD in
other languages but mysteriously don't feel its absence in Haskell. I
probably need to get into better habits.

--Jonathan

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

Re: [Haskell-cafe] Experiences with Intel's manycore lab?

[Johannes Waldmann]

> [1]
http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

Very interesting. Had this been advertised here before?

Besides the technical issues - what kind of personal data does Intel collect?
I understand they're not offering this for fun, but ultimately to sell hardware.

I can live with giving them my office coordinates etc. but I don't like the
idea of  my students having to register with Intel (or any other extra-school
entity) personally, as a requirement for my course.

Opinions? - J.W.


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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Anthony Cowley]

On Wed, Jan 5, 2011 at 3:02 PM, Jonathan Geddes
 wrote:
>> The Haskell type system is simply not rich enough to guarantee everything 
>> you might need.
> Despite all this, I suspect that since Haskell is at a higher level of
> abstraction than other languages, the tests in Haskell must be at a
> correspondingly higher level than the tests in other languages. I can
> see that such tests would give great benefits to the development
> process. I am convinced that I should try to write such tests. But I
> still think that Haskell makes a huge class of tests unnecessary.

The way I think about this is that you want to write tests for things
that can not be usefully represented in the type system. If you have a
parametrically typed function, then the type system is doing a lot of
useful "testing" for you. If you want to make sure that you properly
parse documents in a given format, then having a bunch of examples
that feed into unit tests is a smart move.

Anthony

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Edward Z. Yang]

Haskell's type system makes large classes of traditional "unit tests"
irrelevant.  Here are some examples:

- Tests that simply "run" code to make sure there are no syntax
  errors or typos,

- Tests that exercise simple input validation that is handled by the
  type system, i.e. passing an integer to a function when it
  expects a string,

But, as many other people have mentioned, that doesn't nearly cover all
unit tests (although when I look at some people's unit tests, one might
think this was the case.)

Cheers,
Edward

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

Re: [Haskell-cafe] Building lambdabot

[Rogan Creswick]

On Tue, Jan 4, 2011 at 5:16 PM, Joe Bruce  wrote:
> I've had a bit of an adventure trying to build and run lambdabot on my box.
>  'cabal install lambdabot' does not work.  It states it's not GHC 6.12 (and
> certainly not 7.0) compatible, but I tried 6.12 anyway and got nowhere.

I'm assuming you ran into the mtl-2.0 api changes with respect to
State.  I didn't have any trouble building lambdabot after setting an
upper version bound on the mtl dependency in lambdabot.cabal:

 Library
build-depends: base, mtl <= 2.0, bytestring, unix

I used ghc-6.12.3, and cabal-dev.

--Rogan


>  Next, I tried 6.10 but failed on the unix dependency (in the same manner as
> this thread).  The thread is unresolved, so I've not tried modifying the
> cabal build-depends.  I'm hoping to find someone who has a working lambdabot
> setup who can point me in the right direction.  What further information
> about my struggles should I provide?
> Thanks,
> Joe
> ___
> 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] Building lambdabot

[Rogan Creswick]

On Wed, Jan 5, 2011 at 12:53 PM, Rogan Creswick  wrote:
> State.  I didn't have any trouble building lambdabot after setting an
> upper version bound on the mtl dependency in lambdabot.cabal:
>
>  Library
>    build-depends: base, mtl <= 2.0, bytestring, unix

My mistake, that should be strictly less-than:

  Library
build-depends: base, mtl < 2.0, bytestring, unix

--Rogan

>
> I used ghc-6.12.3, and cabal-dev.
>
> --Rogan
>
>
>>  Next, I tried 6.10 but failed on the unix dependency (in the same manner as
>> this thread).  The thread is unresolved, so I've not tried modifying the
>> cabal build-depends.  I'm hoping to find someone who has a working lambdabot
>> setup who can point me in the right direction.  What further information
>> about my struggles should I provide?
>> Thanks,
>> Joe
>> ___
>> 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] Type System vs Test Driven Development

[Gregory Collins]

On Wed, Jan 5, 2011 at 9:02 PM, Jonathan Geddes
 wrote:

> Despite all this, I suspect that since Haskell is at a higher level of
> abstraction than other languages, the tests in Haskell must be at a
> correspondingly higher level than the tests in other languages. I can
> see that such tests would give great benefits to the development
> process. I am convinced that I should try to write such tests. But I
> still think that Haskell makes a huge class of tests unnecessary.

The testing stuff available in Haskell is top-notch, as others have
pointed out. One of the biggest PITAs with testing in other languages
is having to come up with a set of test cases to fully exercise your
code. If you don't keep code coverage at 100% or close to it, it is
quite easy to test only the inputs you are *expecting* to see (because
programmers are lazy) and end up with something which is quite broken
or even insecure w.r.t. buffer overruns, etc. (Of course we don't
usually have those in Haskell either.)

QuickCheck especially is great because it automates this tedious work:
it fuzzes out the input for you and you get to think in terms of
higher-level invariants when testing your code. Since about six months
ago with the introduction of JUnit XML support in test-framework, we
also have plug-in instrumentation support with continuous integration
tools like Hudson:

  http://buildbot.snapframework.com/job/snap-core/
  http://buildbot.snapframework.com/job/snap-server/

It's also not difficult to set up automated code coverage reports:

  http://buildbot.snapframework.com/job/snap-core/HPC_Test_Coverage_Report/
  http://buildbot.snapframework.com/job/snap-server/HPC_Test_Coverage_Report/

Once I had written the test harness, I spent literally less than a
half-hour setting this up. Highly recommended, even if it is a (blech)
Java program. Testing is one of the few areas where I think our
"software engineering" tooling is on par with or exceeds that which is
available in other languages.

G
-- 
Gregory Collins 

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Iustin Pop]

On Wed, Jan 05, 2011 at 10:27:29PM +0100, Gregory Collins wrote:
> Once I had written the test harness, I spent literally less than a
> half-hour setting this up. Highly recommended, even if it is a (blech)
> Java program. Testing is one of the few areas where I think our
> "software engineering" tooling is on par with or exceeds that which is
> available in other languages.

Indeed, I have found this to be true as well, and have been trying to
explain it to non-Haskellers. Though I would also rank the memory/space
profiler very high compared to what is available for some other
languages.

And note, it's also easy to integrate with the Python-based buildbot, if
one doesn't want to run Java :)

regards,
iustin

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Erik de Castro Lopo]

Jonathan Geddes wrote:

> I know that much of my code could benefit from a property test or two
> on the more complex parts, but other than that I can't think that unit
> testing will improve my Haskell code/programming practice.

One other thing I should mention that is that since a lot of
Haskell code is purely functional its actually easier to test
than imperative code and particularly OO code.

The difficulties in unit testing OO code is coaxing objects
into the correct state to test a particular property. Usually
this means a whole bunch of extra code to implement mock
objects to feed the right data to the object under test.

By contrast, much Haskell code is purely functional. With
pure functions there is no state that needs to be set up. For
testing pure functions, its just a matter of collecting a set
of representative inputs and making sure the correct output is
generated by each input. For example, Don Stewart reported that
the XMonad developers conciously made as much of the XMonad code
pure so it was more easily testable.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[John Zabroski]

These are some heuristics & memories I have for myself, and you can feel
free to take whatever usefulness you can get out of it.

1. Don't confuse TDD with writing tests, in general.

2. Studies show that if you do TDD, you can write more tests than if you
write tests after you write the code.  Therefore, TDD is the most productive
way to test your code.

3. TDD has nothing to do with what language you are using; if you want a
great book on TDD, I'd recommend Nat Pryce and Steve Freeman's Growing
Object-Oriented Software; it has nothing to do with Haskell but everything
to do with attitude towards software process.  A language is not enough to
dramatically improve quality, you need a sane process.  Picking a good
language is just as important as picking a sane process, and the two go
hand-in-hand in creating great results.

4. Haskell's type system gives you confidence, not certainty, that you are
correct.  Understand the difference.  The value of TDD is that the tests
force you to think through your functional and non-functional requirements,
before you write the code.

5. I have a hard time understanding statements like "The difficulties in
unit testing OO code is coaxing objects into the correct state to test a
particular property."  Difficulty in unit testing OO code is best documented
in Robert Binder's tome [1], which is easily the best text on testing I've
ever read and never gets cited by bloggers and other Internet programmarazzi
(after all, who has time to read 1,500 pages on testing when you have to
maintain a blog).  Moreover, you should not be mocking objects.  That will
lead to a combinatorial explosion in tests and likely reveal that your
object model leaks encapsulation details (think about it).  Mock the role
the object plays in the system instead; this is kind of a silly way to say
"use abstraction" but I've found most people need to hear a good idea 3
different ways in 3 different contexts before they can apply it beyond one
playground trick.

6. If you care about individual objects, use design by contract and try to
write your code as stateless as possible; design by contract is
significantly different from TDD.

7. Difficulty in testing objects depends on how you describe object
behavior, and has nothing to do with any properties of objects as compared
with abstract data types!  For example, if object actions are governed by an
event system, then to test an interaction, you simply mock the event queue
manager.  This is because you've isolated your test to three variants: (A)
the state prior to an atomic action, (B) the state after that action, and
(C) any events the action generates.   This is really not any more
complicated than using QuickCheck, but unfortunately most programmers are
only familiar with using xUnit libraries for unit testing and they have
subdued the concept of "unit testing" to a common API that is not
particularly powerful.  Also, note earlier my dislike of the argument that
"The difficulties in unit testing OO code is coaxing objects into the
correct state to test a particular property."; under this testing
methodology, there is no "particular property" to test, since the state of
the application is defined in terms of all the object's attributes *after*
the action has been processed.  It doesn't make much sense to just test one
property.  It's called unit testing, not property testing.

8. If you've got a complicated problem, TDD will force you to decompose it
before trying to solve it.  This is sort of a silly point, again, since more
naturally good programmers don't waste their time writing random code first
and then trying to debug it.  Most naturally good programmers will think
through the requirements and write it correctly the first time.  TDD is in
some sense just a bondage & discipline slogan for the rest of us mere
mortals; you get no safety word, however.  You just have to keep at it.

9. Watch John Hughes' Functional Programming Secret Weapon talk [2].  I'd
recommend watching it if you haven't already.

10. Watch and learn.  Google "QuickCheck TDD" [3] and see what comes up.
Maybe you can be inspired by real world examples?

[1] http://www.amazon.com/dp/0201809389
[2] http://video.google.com/videoplay?docid=4655369445141008672
[3] http://www.google.com/search?q=QuickCheck+TDD
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Choosing a type-class instance based on the context

[Cristiano Paris]

On Wed, Jan 5, 2011 at 20:35, Stephen Tetley  wrote:
> Though its quite different to AdvancedOverlap, Conal Elliott has a
> method of answering the title of your post - "Choosing a type-class
> instance based on the context".
>
> See the CxMonoid (context monoid) in Section 3. Flexible Layout of the
> paper Applicative Data-Driven Computation.
>
> http://conal.net/papers/data-driven/paper.pdf

Thank you Stephen. I'll read it and come back to this ml.

Regards,

-- 
Cristiano

GPG Key: 4096R/C17E53C6 2010-02-22
Fingerprint = 4575 4FB5 DC8E 7641 D3D8  8EBE DF59 B4E9 C17E 53C6

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[John Zabroski]

On Wed, Jan 5, 2011 at 6:41 PM, John Zabroski wrote:

>
> 5. I have a hard time understanding statements like "The difficulties in
> unit testing OO code is coaxing objects into the correct state to test a
> particular property."  Difficulty in unit testing OO code is best documented
> in Robert Binder's tome [1], which is easily the best text on testing I've
> ever read and never gets cited by bloggers and other Internet programmarazzi
> (after all, who has time to read 1,500 pages on testing when you have to
> maintain a blog).  Moreover, you should not be mocking objects.  That will
> lead to a combinatorial explosion in tests and likely reveal that your
> object model leaks encapsulation details (think about it).  Mock the role
> the object plays in the system instead; this is kind of a silly way to say
> "use abstraction" but I've found most people need to hear a good idea 3
> different ways in 3 different contexts before they can apply it beyond one
> playground trick.
>
>
> 7. Difficulty in testing objects depends on how you describe object
> behavior, and has nothing to do with any properties of objects as compared
> with abstract data types!  For example, if object actions are governed by an
> event system, then to test an interaction, you simply mock the event queue
> manager.  This is because you've isolated your test to three variants: (A)
> the state prior to an atomic action, (B) the state after that action, and
> (C) any events the action generates.   This is really not any more
> complicated than using QuickCheck, but unfortunately most programmers are
> only familiar with using xUnit libraries for unit testing and they have
> subdued the concept of "unit testing" to a common API that is not
> particularly powerful.  Also, note earlier my dislike of the argument that
> "The difficulties in unit testing OO code is coaxing objects into the
> correct state to test a particular property."; under this testing
> methodology, there is no "particular property" to test, since the state of
> the application is defined in terms of all the object's attributes *after*
> the action has been processed.  It doesn't make much sense to just test one
> property.  It's called unit testing, not property testing.
>

One small update for pedagogic purposes: Testing properties is really just a
form of testing called negative testing; testing that something doesn't do
something it shouldn't do.  The testing I covered above describes positive
testing.  Negative testing is always going to be difficult, regardless of
how you abstract your system and what language you use.  Think about it!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] What's the best seed for random API ?

[z_axis]

picoSec :: IO Integer
picoSec = do
t <- ctPicosec `liftM` (getClockTime >>= toCalendarTime)
return t

rollDice ::  Int -> IO Int
rollDice n = do
ps <- picoSec
return $ (take 1 $ randomRs (1,n) $ mkStdGen $ fromInteger ps) !! 0

The above code uses `ctPicosec` as seed. Is it better to use the output of
/dev/urandom as seed ?

Sincerely!

-
e^(π.i) + 1 = 0
-- 
View this message in context: 
http://haskell.1045720.n5.nabble.com/What-s-the-best-seed-for-random-API-tp3329807p3329807.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Erik de Castro Lopo]

John Zabroski wrote:

> 5. I have a hard time understanding statements like "The difficulties in
> unit testing OO code is coaxing objects into the correct state to test a
> particular property."

This is my direct experience of inheriting code written by others
without any tests and trying to add tests before doing more serious
work on extending and enhancing the code base.

> Difficulty in unit testing OO code is best documented
> in Robert Binder's tome [1],

I'm sure thats a fine book for testing OO code. I'm trying to avoid
OO code as much as possible :-).

My main point was that testing pure functions is easy and obvious
in comparison to test objects with internal state.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] What's the best seed for random API ?

[Alex Rozenshteyn]

Admittedly, I don't know much about this from the haskell end or about the
particular api.

If you want statistical randomness, your seed doesn't matter; just the PRNG.
 I might even have seeded with a constant or taken the seed from the user.

Seeding from urandom will make your output "more random" for some
unquantifiable meaning of the phrase.

If you want cryptographic randomness, you probably shouldn't be writing your
own library if you can avoid it.

On Wed, Jan 5, 2011 at 7:21 PM, z_axis  wrote:

>
> picoSec :: IO Integer
> picoSec = do
>t <- ctPicosec `liftM` (getClockTime >>= toCalendarTime)
>return t
>
> rollDice ::  Int -> IO Int
> rollDice n = do
>ps <- picoSec
>return $ (take 1 $ randomRs (1,n) $ mkStdGen $ fromInteger ps) !! 0
>
> The above code uses `ctPicosec` as seed. Is it better to use the output of
> /dev/urandom as seed ?
>
> Sincerely!
>
> -
> e^(π.i) + 1 = 0
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/What-s-the-best-seed-for-random-API-tp3329807p3329807.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] What's the best seed for random API ?

[Robert Clausecker]

It probably is, but definitly not portable. Try to find /dev/urandom
under Windows.

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Evan Laforge]

On Wed, Jan 5, 2011 at 1:27 PM, Gregory Collins  wrote:
> On Wed, Jan 5, 2011 at 9:02 PM, Jonathan Geddes
>  wrote:
>
>> Despite all this, I suspect that since Haskell is at a higher level of
>> abstraction than other languages, the tests in Haskell must be at a
>> correspondingly higher level than the tests in other languages. I can
>> see that such tests would give great benefits to the development
>> process. I am convinced that I should try to write such tests. But I
>> still think that Haskell makes a huge class of tests unnecessary.

I write plenty of tests.  Where static typing helps is that of course
I don't write tests for type errors, and more things are type errors
than might be in other languages (such as incomplete cases).  But I
write plenty of tests to verify high level relations: with this input,
I expect this kind of output.

A cheap analogue to "test driven" that I often do is "type driven", I
write down the types and functions with the hard bits filled in with
'undefined'.  Then I :reload the module until it typechecks.  Then I
write tests against the hard bits, and run the test in ghci until it
passes.

However:

> QuickCheck especially is great because it automates this tedious work:
> it fuzzes out the input for you and you get to think in terms of
> higher-level invariants when testing your code. Since about six months
> ago with the introduction of JUnit XML support in test-framework, we
> also have plug-in instrumentation support with continuous integration
> tools like Hudson:

Incidentally, I've never been able to figure out how to use
QuickCheck.  Maybe it has more to do with my particular app, but
QuickCheck seems to expect simple input data and simple properties
that should hold relating the input and output, and in my experience
that's almost never true.  For instance, I want to ascertain that a
function is true for "compatible" signals and false for "incompatible"
ones, where the definition of compatible is quirky and complex.  I can
make quickcheck generate lots of random signals, but to make sure the
"compatible" is right means reimplementing the "compatible" function.
Or I just pick a few example inputs and expected outputs.  To get
abstract enough that I'm not simply reimplementing the function under
test, I have to move to a higher level, and say that notes that have
incompatible signals should be distributed among synthesizers so they
don't make each other sound funny.  But now it's too high level: I
need a definition of "sound funny" and a model of a synthesizer... way
too much work and it's fuzzy anyway.  And at this level the input data
is complex enough that I'd have to spend a lot of time writing and
tweaking (and testing!) the data generator to verify it's covering the
part of the state space I want to verify.

I keep trying to think of ways to use QuickCheck, and keep failing.

In my experience, the main work of testing devolves to a library of
functions to create the input data, occasionally very complex, and a
library of functions to extract the interesting bits from the output
data, which is often also very complex.  Then it's just a matter of
'equal (extract (function (generate input data))) "abstract
representation of output data"'.  This is how I do testing in python
too, so I don't think it's particularly haskell-specific.

I initially tried to use the test-framework stuff and HUnit, but for
some reason it was really complicated and confusing to me, so I gave
up and wrote my own that just runs all functions starting with
'test_'.  It means I don't get to use the fancy tools, but I'm not
sure I need them.  A standard profile output to go into a tool to draw
some nice graphs of performance after each commit would be nice
though, surely there is such a thing out there?

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Chung-chieh Shan]

Evan Laforge  wrote in article 
 in 
gmane.comp.lang.haskell.cafe:
> Incidentally, I've never been able to figure out how to use
> QuickCheck.  Maybe it has more to do with my particular app, but
> QuickCheck seems to expect simple input data and simple properties
> that should hold relating the input and output, and in my experience
> that's almost never true.  For instance, I want to ascertain that a
> function is true for "compatible" signals and false for "incompatible"
> ones, where the definition of compatible is quirky and complex.  I can
> make quickcheck generate lots of random signals, but to make sure the
> "compatible" is right means reimplementing the "compatible" function.
> Or I just pick a few example inputs and expected outputs.

Besides those example inputs and expected outputs, what about:
If two signals are (in)compatible then after applying some simple
transformations to both they remain (in)compatible?  A certain family of
signals is always compatible with another family of signals?  Silence is
compatible with every signal?  Every non-silent signal is (in)compatible
with itself (perhaps after applying a transformation)?

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig



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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Jesse Schalken]

You need both. A good static type system will tell you whether or not the
code is type-correct. It will not tell you whether or not it does what it's
supposed to do.

Consider:

sort :: [a] -> [a]


If you change sort to be:

sort = id


It will still type check, but it obviously doesn't do what it's supposed to
do anymore. You need tests to verify that.

If you then change sort to be:

sort _ = 5


Now it's also type-incorrect. Static typing will catch it at compile
time (eg. Haskell will now infer the type as "Num b => a -> b" which will
not unify with "[a] -> [a]"), and dynamic typing will likely throw some sort
of type error at run time in the places it was previously used. (Any error
thrown by the language itself, like PHP's "Cannot call method on non-object"
or Python's "TypeError" or even Java's "NullPointerException" or C++'s
"Segmentation Fault" can be considered a type error.)

So with static typing, the machine will verify type-correctness, but you
still need tests to verify the program meets its specification. With dynamic
typing, you need tests to verify that the program meets both its
specification *and* doesn't throw any type errors - so you need to test
more.

The fact that most errors in programming are type errors and that Haskell
programs therefore tend to "just work" once you can get them past the type
checker may lead you to believe you don't need to test at all. But you still
do for the reasons above, you just need to test a hell of a lot less.

On Wed, Jan 5, 2011 at 8:44 PM, Jonathan Geddes
wrote:

> Cafe,
>
> In every language I program in, I try to be as disciplined as possible
> and use Test-Driven Development. That is, every language except
> Haskell.
>
> There are a few great benefits that come from having a comprehensive
> test suite with your application:
>
> 1. Refactoring is safer/easier
> 2. You have higher confidence in your code
> 3. You have a sort of 'beacon' to show where code breakage occurs
>
> Admittedly, I don't believe there is any magical benefit that comes
> from writing your tests before your code. But I find that when I don't
> write tests first, it is incredibly hard to go back and write them for
> 'completed' code.
>
> But as mentioned, I don't write unit tests in Haskell. Here's why not.
>
> When I write Haskell code, I write functions (and monadic actions)
> that are either a) so trivial that writing any kind of unit/property
> test seems silly, or are b) composed of other trivial functions using
> equally-trivial combinators.
>
> So, am I missing the benefits of TDD in my Haskell code?
>
> Is the refactoring I do in Haskell less safe? I don't think so. I
> would assert that there is no such thing as refactoring with the style
> of Haskell I described: the code is already super-factored, so any
> code reorganization would be better described as "recomposition." When
> "recomposing" a program, its incredibly rare for the type system to
> miss an introduced error, in my experience.
>
> Am I less confidence in my Haskell code? On the contrary. In general,
> I feel more confident in Haskell code WITHOUT unit tests than code in
> other languages WITH unit tests!
>
> Finally, am I missing the "error beacon" when things break? Again I
> feel like the type system has got me covered here. One of the things
> that immediately appealed to me about Haskell is that the strong type
> system gives the feeling of writing code against a solid test base.
>
> The irony is that the type system (specifically the IO monad) force
> you to structure code that would be very easy to test because logic
> code is generally separated from IO code.
>
> I explained these thoughts to a fellow programmer who is not familiar
> with Haskell and his response was essentially that any language that
> discourages you from writing unit tests is a very poor language. He
> (mis)quoted: "compilation [is] the weakest form of unit testing" [0].
> I vehemently disagreed, stating that invariants embedded in the type
> system are stronger than any other form of assuring correctness I know
> of.
>
> I know that much of my code could benefit from a property test or two
> on the more complex parts, but other than that I can't think that unit
> testing will improve my Haskell code/programming practice. Am I
> putting too much faith in the type system?
>
> [0]
> http://blog.jayfields.com/2008/02/static-typing-considered-harmful.html
>
> ___
> 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] UTF-8 BOM

[Mark Lentczner]

On Jan 4, 2011, at 5:41 PM, Antoine Latter wrote:

> Are you thinking that the BOM should be automatically stripped from
> UTF8 text at some low level, if present?

It should not. Wether or not a U+FFEF can be stripped depends on context in 
which it is found. There is no way that lower level code, even file primitives, 
can know this context.

> I'm thinking that it would be correct behavior to drop the BOM from
> the start of a UTF8 stream, even at a pretty low level. The FAQ seems
> to allow it as a means of identifying the stream as UTF8 (although it
> isn't a reliable means of identifying a stream as UTF8).

§3.9 and §3.10 of the Unicode standard go into more depth on the issue and make 
things more clear. A leading U+FFEF is considered "not part of the text", and 
dropped, only in the case that the encoding is UTF-16 or UTF-32. In all other 
cases (including the -BE and -LE variants of UTF-16 and UTF-32) the U+FFEF 
character is retained.

The FAQ states that a leading byte sequence of EF BB BF in a stream indicates 
that the stream is UTF-8, though it doesn't go so far as to say that it can be 
stripped. Since Unicode doesn't want to encourage the use of BOM in UTF-8 (see 
end of §3.10), I imagine they don't want to promulgate it as a useful encoding 
indicator.

So, it might be reasonable that when opening a file in UTF-16 mode (not 
UTF-16BE or UTF-16LE), that the system should read the initial bytes, determine 
the byte order, and remove the BOM if present[1]. But it isn't safe or correct 
to do this for UTF-8.


On Jan 4, 2011, at 5:08 PM, Tony Morris wrote:

> I am reading files with System.IO.readFile. Some of these files start
> with a UTF-8 Byte Order Marker (0xef 0xbb 0xbf). For some functions that
> process this String, this causes choking so I drop the BOM as shown
> below.

If you mean functions in the standard libs shouldn't have any problems with the 
BOM character. If they do, these are bugs.

On the other hand, if you know the context of the files, and know for certain 
that the leading BOM is intended only as an encoding indicator, then by all 
means strip it off. But only you can know if this is true for your application, 
the system cannot. If so, your code doesn't look hackish to me at all. I'd only 
perhaps tidy up dropBOM a bit (but this is pure stylistic choice):

readBomFile :: FilePath -> IO String
readBomFile p = dropBom `fmap` readFile p
  where
dropBom (\xffef:s) = s  -- U+FFEF at the start is a BOM
dropBom s = s

I'd keep dropBom private to readBomFile to ensure that it isn't used on 
arbitrary strings, since it is really only valid at the start of an encoded 
stream.
 
- Mark


[1] Software reading a single text stream that has been split across files 
would have a problem here. But this is perhaps an obscure and unlikely case.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Odd profiling results

[Erik de Castro Lopo]

Simon Marlow wrote:

> Or the C compiler, perhaps?

Thanks for the suggesion Simon. This one was actually easier
to test that Malcolm's suggestion.

To test it, I ran the same test under Oprofile [0], the Linux
kernel based profiler. OProfile is really cool because it
profiles the whole system, from user space all the way down to
the most insignificant kernel driver (eg allows you to see if
a kernel driver is causing your user space code to do something
weird).

My first run showed the GHC RTS profiling code being one of the
biggest runtime costs. After recompiling without profiling the
biggest CPU hogs were as follows (editied slightly for clarity
and severely truncated for brevity):

  samples  %  image nameapp name  symbol name
  -
  128328  7.7305  ddc   ddc   evacuate
  97663   5.8832  ddc   ddc   s1PI_info
  91177   5.4925  ddc   ddc   stg_ap_pp_fast
  72926   4.3931  ddc   ddc   s1PV_info
  70650   4.2559  ddc   ddc   s1PJ_info
  62956   3.7925  ddc   ddc   s19S_info
  51240   3.0867  ddc   ddc   stg_ap_p_fast
  50197   3.0239  ddc   ddc   stg_upd_frame_info
  47797   2.8793  ddc   ddc   stg_PAP_apply
  39764   2.3954  ddc   ddc   sNr_info
  39351   2.3705  ddc   ddc   stg_ap_p_info
  38339   2.3095  ddc   ddc   stg_ap_pp_info
  30283   1.8242  cc1   cc1   
/usr/lib/gcc/x86_64-linux-gnu/4.4/cc1
  29733   1.7911  ddc   ddc   scavenge_block
  27062   1.6302  ddc   ddc   base_GHCziBase_zdfOrdChar3_info
  23620   1.4229  ddc   ddc   s1PK_info
  21671   1.3055  ddc   ddc   s19R_info
  19043   1.1471  ddc   ddc   base_GHCziClasses_DZCOrd_con_info
  18090   1.0897  ddc   ddc   sAD_info
  16500   0.9940  ddc   ddc   sAE_info
  14978   0.9023  ddc   ddc   sxb_info
  13862   0.8350  ddc   ddc   stg_ap_0_fast
  12975   0.7816  ddc   ddc   stg_IND_STATIC_info
  12553   0.7562  ddc   ddc   
base_GHCziClasses_DZCOrd_static_info

The C compiler is down there at %1.82 of total run time and definitely
not the culprit.

I've been discussing this with Ben as well and on the basis of this
plot that Ben captured:

http://deluge.ouroborus.net/~benl/tmp/ddc-comp.pdf

we ought to be looking at scrapeRecursive.

Cheers,
Erik

[0] http://oprofile.sourceforge.net/
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] Building lambdabot

[Joe Bruce]

Rogan,

Thanks for taking a look at it.  No, mtl is not the problem, at least not
yet.

A detail that I've discovered is important: I'm on Mac OS X (10.6).
 readline is my problem, and readline + mac + haskell seems to be a bad mix.

Macports installs readline in /opt/local/ by default, so I discovered I
needed to install this way:
cabal install lambdabot
--configure-option=--with-readline-includes="/opt/local/include"
--configure-option=--with-readline-libraries="/opt/local/lib"

That got the readline dependency installed correctly, but then the lambdabot
build complained about the architecture (32- vs 64-bit).  This
thread
was
somewhat helpful.  I reinstalled readline via macports with the universal
flag and got past that error.

Now I'm stuck on readline again [lambdabot build step 28 of 81]:
"/Users/joe/.cabal/lib/readline-1.0.1.0/ghc-6.12.3/HSreadline-1.0.1.0.o:
unknown symbol `_rl_basic_quote_characters'"

What do I do with that?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type System vs Test Driven Development

[Arnaud Bailly]

I would supplement this excellent list of advices with an emphasis on
the first one: Test-Driven Development is *not* testing, TDD is a
*design* process. Like you said, it is a discipline of thought that
forces you first to express your intent with a test, second to write
the simplest thing that can possibly succeed, third to remove
duplication and refactor your code.

It happens that this process is somewhat different in Haskell than in
say Java, and actually much more fun and interesting thanks to the
high signal-to-noise ratio syntax of Haskell (once you get acquainted
with it of course) and its excellent support for abstaction,
duplication removal, generalization and more generally refactoring
(tool support may be better though...). For example, if I were to
develop map in TDD (which I did actually...), I could start with the
following unit test:

> map id  [] ~?= []

which I would make pass very simply by copy and pasting, only changing
one symbol.

> map id  [] = []

Then I would add a failing test case:

> TestList [ map id  [] ~?= [] , map id [1] ~?= [1] ]

which I would make pass with, once again simple copy-pasting:

> map id  []   = []
> map id  [1] = [1]

Next test could be :

> TestList [ map id  [] ~?= [] , map id [1] ~?= [1], , map id [2] ~?= [2] ]

Which of course would pass with:

> map id  []   = []
> map id  [1] = [1]
> map id  [2] = [2]

then I would notice an opportunity for refactoring:

> map id  []   = []
> map id  [x] = [x]

etc, etc...Sound silly? Sure it is at first sight, and any
self-respecting haskeller would write such a piece, just like you
said, without feeling the need to write the tests, simply by stating
the equations about map.

The nice thing with haskell is that it has a few features that helps
in making those bigger steps in TDD, whereas less gifted languages and
platforms requires a lot more experience and self-confidence to "start
running":
 - writing types delivers some of the design burden off the tests,
while keeping their intent (being executable instead of laying in dead
trees),
 - quickcheck and friends help you express a whole class of those unit
tests in one invariant expression, while keeping the spirit of TDD as
one can use the counter-examples produced to drive the code-writing
process.


Some people might be interested in
http://www.oqube.net/projects/beyond-tdd/ (a session I co-presented at
SPA2009) which was an experiment to try bringing the benefits of TDD
with quickcheck in haskell to the java world.


Regards,
Arnaud

PS: On

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