Re: Perspectives on learning and using Haskell

2004-01-03 Thread ajb
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 Foo ( publicFoo ) where
> import FooInternals
>
> module FooDebug ( publicFoo, debugFoo ) where
> import FooInternals

I would put debugFoo in FooDebug, and not export publicFoo.  The former
is an advantage because unit test code doesn't end up in the executable,
and the latter is an advantage because it turns a triple maintenance
problem into a double maintenance problem.  (Should you add a new public
function to FooInternals, you only have to mention it in Foo and not in
FooDebug as well.)

The reason why this is inelegant is that in Haskell, the unit of
abstraction (i.e. the module) is the same as the unit of compilation
(i.e. the file).  If there are some budding researchers who are looking
for a topic, I'd love a way to split a module across files without the
situation degenerating into C-style textual inclusion.

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Perspectives on learning and using Haskell

2004-01-03 Thread ajb
G'day all.

Quoting Derek Elkins <[EMAIL PROTECTED]>:

> The "nicer" way*, though it could use less typing and "extraneous"
> files, is simply use multiple modules.

Yes, this was my solution, too.  Nested modules might make this even
nicer.

Of course, Haskell's module system could do with a redesign, but that's
another topic. :-)

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe