[Haskell-cafe] Re: Default (or empty) values
max.vasin at gmail.com
Wed Jan 17 10:47:13 EST 2007
>>>>> "Colin" == Colin DeVilbiss <cdevilbiss at gmail.com> writes:
Colin> On 1/17/07, Max Vasin <max.vasin at gmail.com> 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> 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).
> 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,
More information about the Haskell-Cafe