[m-dev.] Array modes

Peter Wang novalazy at gmail.com
Mon Oct 27 12:05:01 AEDT 2014


On Sat, 25 Oct 2014 18:26:47 +1100, Mark Brown <mark at mercurylang.org> wrote:
> On Sat, Oct 25, 2014 at 4:28 PM, Julien Fischer <jfischer at opturion.com> wrote:
> >
> > Hi,
> >
> > On Sat, 25 Oct 2014, Zoltan Somogyi wrote:
> >
> >> On Sat, 25 Oct 2014 15:32:10 +1100, Mark Brown <mark at mercurylang.org>
> >> wrote:
> >>>
> >>> I think these "bogus" constructors are really useful for foreign types
> >>> that act as containers for Mercury terms, of which arrays are one
> >>> example, so I don't agree with disallowing them entirely as is
> >>> suggested in that thread.
> >>
> >>
> >> I have long thought that having insts that are not bound to a specific
> >> type
> >> is a bad idea. I would even support a change in the language to require
> >> each inst definition to say what type it is for.
> 
> That's fine. In this case the inst would be bound to the foreign type
> array/1, and be immediately recognised as a "bogus" constructor.

I agree with requiring types on insts as well.


An interesting use for bogus insts may be to track the state of
foreign type handles, e.g.

    :- type db.
    :- pragma foreign_type("C", db, "DB *").

    :- type db_state
	--->    open
	;       txn.

    :- pred open(db::out(unique(open))) is det.
    :- pred begin_transaction(db::di(unique(open)), db::out(unique(txn)))
	is det.
    :- pred write(db::di(unique(txn)), db::out(unique(txn))) is det.
    :- pred end_transaction(db::di(unique(txn)), db::out(unique(open)))
	is det.
    :- pred close(db::di(unique(open))) is det.

With nested uniqueness you could wrap the handle with a Mercury type
instead.

Peter



More information about the developers mailing list