[mercury-users] Bit-fields in Mercury

[Michael Day]

> Could you give an example where that would be useful.  Why not just
> ignore the argument(s) if you're not interested in them?

Being able to separate the name and the value allows you to write more
generic code. For example, you can lookup/store things by name. If the
name and value are coupled, then it's more difficult:

:- type opt
    --->    opt1(int)
    ;       opt2(string).

If I have a list(opt) then the only way to retrieve the value for opt2 is
to use member:

    member(opt2(Value), Opts)

However, I can't do this at one remove, by passing in the value I want to
get, eg.

    Value = get_me(opt2, Opts)

which can be a real stumbling block. Also, I can't use a map or other data
structure to store opts, as the name and the value are coupled together.

One workaround is to define two types, and duplicate the name like this:

:- type opt_name
   --->    opt1
   ;       opt2.

:- func opt_get_name(opt) = opt_name.

opt_get_name(opt1(_)) = opt1.
opt_get_name(opt2(_)) = opt2.

Then you can have map(opt_name, opt). But in general the lack of dependent
types leads to an awkward tradeoff for this kind of code, where you either
have to give up genericity/conciseness in favour of strict typing or just
use variant types for everything and lose some type safety to make the
code shorter.

(The particular issue that concerns me is of course CSS properties).

Michael

-- 
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at csse.unimelb.edu.au
administrative address: owner-mercury-users at csse.unimelb.edu.au
unsubscribe: Address: mercury-users-request at csse.unimelb.edu.au Message: unsubscribe
subscribe:   Address: mercury-users-request at csse.unimelb.edu.au Message: subscribe
--------------------------------------------------------------------------