[EMAIL PROTECTED] writes:
There is only one problem I've found with test-driven development in
Haskell. In C++, it's possible to break the module abstraction
(yes, I know, C++ doesn't have modules; it has classes, which are really
instantiable modules) by using friend. In Haskell, I find
Duncan Coutts wrote:
On Sun, 2004-01-04 at 10:20, Graham Klyne wrote:
[...] I would expect that when using GHC to compile a
stand-alone Haskell program, any expressions that are not referenced are
not included in the final object program, so leaving these test cases
uncommented would be
At 21:07 01/01/04 -0500, [EMAIL PROTECTED] wrote:
In Haskell, I find myself
occasionally having to expose parts of a module which I would prefer not
to, in order for the unit tests suite to do their job effectively.
Yes, I've found that too.
But I also wonder if this is a sign that the XP
At 12:23 02/01/04 +, Jon Fairbairn wrote:
The compiler would then (optionally?) run the tests as part
of the compilation. This would bind the tests more tightly
to the programme than is now possible.
Ooh! There's an interesting idea. I guess it's like a kind of 'assert'
that get's optimized
On Sun, 2004-01-04 at 10:20, Graham Klyne wrote:
Which leads to a question: I've been thinking that the white box tests
may be better served by test expressions coded *within* the module
concerned. In many cases, I create these, then en-comment them when the
code is working. I would
G'day all.
Quoting Graham Klyne [EMAIL PROTECTED]:
But I also wonder if this is a sign that the XP approach to test-led
development isn't being followed faithfully. Theoretically (as I
understand XP), the tests *are* the specification. And things that aren't
exposed can't be part of the
G'day all.
One small note on style while I think of it.
Quoting Derek Elkins [EMAIL PROTECTED]:
module FooInternals where
publicFoo :: Foo - Bar
publicFoo x = privateFrob x
privateFrob x :: Foo - Bar
privateFrob x = ...
debugFoo :: (Foo - Bar) - Foo - Bar
debugFoo f x = ...
module
On Thu, 1 Jan 2004 21:07:00 -0500
[EMAIL PROTECTED] wrote:
(6) I have found that Haskell seems to a particularly effective
platform for pursuing some ideas of extreme programming,
There you go. :-)
There is only one problem I've found with test-driven development in
Haskell. In C++,
On 2004-01-01 at 21:07EST [EMAIL PROTECTED] wrote:
There is only one problem I've found with test-driven development in
Haskell. In C++, it's possible to break the module abstraction
(yes, I know, C++ doesn't have modules; it has classes, which are really
instantiable modules) by using
At 17:44 23/12/03 -0500, Derek Elkins wrote:
On Tue, 23 Dec 2003 17:26:20 +
Graham Klyne [EMAIL PROTECTED] wrote:
(moved to Haskell-Cafe as this reply might generate several more)
I've spent part of the past few months learning Haskell and developing
a moderately sized application. I came
G'day all.
Quoting Graham Klyne [EMAIL PROTECTED]:
(2) I find that I spend a far greater portion of my time *thinking* about
what I'm trying to do than actually coding it. There used to be an adage
in the software industry that programmer productivity in lines-of-code per
day was
[switching to Haskell-cafe]
At 19:37 23/12/03 +0100, Tomasz Zielonka wrote:
On Tue, Dec 23, 2003 at 05:26:20PM +, Graham Klyne wrote:
[1] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html
Thanks, that was a nice reading :)
Thanks!
(If by any chance there's anything here that
On Wed, Dec 24, 2003 at 10:39:33AM +, Graham Klyne wrote:
It now seems to me that (some?) Monads are kinds of Functors, generalized
to handle the no value case, and also composition.
This also had me thinking about sequence: is there a generalization to
arbitrary monads that
On Tue, 23 Dec 2003 17:26:20 +
Graham Klyne [EMAIL PROTECTED] wrote:
(moved to Haskell-Cafe as this reply might generate several more)
I've spent part of the past few months learning Haskell and developing
a moderately sized application. I came to this from a long background
(20 years or
14 matches
Mail list logo
