[Haskell-cafe] Re: Default (or empty) values

...

...

...

...

"Colin" == Colin DeVilbiss writes:

Colin> On 1/17/07, Max Vasin wrote:

...

Fields of the Book datatype which are not (Maybe a) are required to be present.

Colin> This doesn't actually answer your question, but if those Colin> fields are really required and you want to avoid the Colin> possibility of a "default" value sneaking into the program Colin> through a bug, you may prefer to use undefined instead of a Colin> non-bottom value for the required fields. That is, Colin> Book undefined undefined Nothing Nothing Nothing undefined Colin> undefined undefined Hmm that's interesting... Colin> (lots of typing, but if a bug slips in and you get a Colin> partially-defined book into the guts of the program, you'll Colin> die instead of silently using invalid data.)

...

...

class Empty e where > empty :: e

But still I have to emplement instances by hand.

Colin> What would the strategy be here for automatically defining Colin> the instances? For example, what are the Empty instances Colin> for Colin> data Foo = Bar | Baz | Quux data Foo2 = Bar2 Int | Baz2 Colin> String | Quux2 (Maybe String) In my program (a BibTeX analog) Empty instances will be defined for datatypes representing bibliography entries which will have only one value constructor (records can't be used with newtype AFIAK). So for

data Foo = Foo t1 t2 ... tN

instance Empty Foo where empty = Foo (empty :: t1) (empty :: t2) ... (empty :: tN)

...

Or may be it would be better to drop out Empty and use something else? Colin> I see no inherent problem with Empty, just with the Colin> automated instantiation. Then again, I'd be tempted to Colin> wait to define Empty until I saw the second or third Colin> instance of its use.

There will be datatypes representing books, articles, thesis, reports, etc. -- WBR, Max Vasin.