[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