[m-dev.] generic result types

[Julien Fischer]

On Wed, 18 Feb 2009, Peter Ross wrote:

> On Wed, Feb 18, 2009 at 2:44 PM, Julien Fischer
> <juliensf at csse.unimelb.edu.au> wrote:
>>
>> On Wed, 18 Feb 2009, Peter Ross wrote:
>>
>>> Hi,
>>>
>>> Do people think it would be useful to add the following generic types
>>> to the standard library?
>>>
>>> :- type result(T, E)
>>>   --->    ok(T)
>>>   ;       error(E)
>>>   .
>>>
>>> :- type partial_result(T, E) == partial_result(T, T, E).
>>>
>>> :- type partial_result(T, P, E)
>>>   --->    ok(T)
>>>   ;       error(P, E)
>>>
>>> :- type result(E)
>>>   --->    ok
>>>   ;       error(E)
>>>   .
>>
>> result/2 and result/1 almost already exist in the form of the
>> maybe_error/[01] types.  Making them polymoprhic in the error type would
>> give you the above.  Maybe, maybe_partial_result/3 could be added to the
>> maybe module?
>>
> Good find, you are right they are essentially the same types.

So, I propose that we make them the same types by making them
polymorphic in the error type and the redefining the existing ones
as equivlance types, for example:

 	:- type maybe_error(T) == maybe_error(T, string).

and the same for the relevant ones in the I/O and stream modules.
(This shouldn't break backwards compatability in such a huge way since
most non-trivial Mercury modules already import the maybe module
anyway.)

> I prefer the name result though, mainly because this is the name io
> uses and so it seems more "natural" to me.

Also maybe_partial_error doesn't make a great deal of sense!

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------