[mercury-users] Bit-fields in Mercury

[Michael Day]

> How about having a separate type for each kind of option, and a type
> class for 'option'.  Then you could have to have methods for all the
> different ways you want to handle the options, with a separate
> implementation for each option.  That way each method can deal with
> the data attached to each option in the appropriate way.  It might
> wind up being too verbose and painful, and it may be awkward to have
> the option handling all in separate methods rather than in one
> predicate, but at least the type system won't get in your way, and
> you'll still have type safety and ease of introducing new options.

Yes, that is another way to do it, although to have a map of these
existentially typed options you would probably still need to use the
separate opt_name trick. Again, you can keep the strict typing if you
accept more verbosity, but the verbosity can be a nuisance once you have
more than one or two hundred options. (And not just an aesthetic nuisance
if it results in predicates of an inconvenient size that push the limits
of the compiler).

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
--------------------------------------------------------------------------