[m-rev.] for review: add `any_is_bound' pragma

David Overton dmo at cs.mu.OZ.AU
Fri Jul 18 09:09:43 AEST 2003


On Thu, Jul 17, 2003 at 11:39:49PM +1000, Fergus Henderson wrote:
> On 17-Jul-2003, David Overton <dmo at cs.mu.OZ.AU> wrote:
> > 
> > This change adds a new pragma `any_is_bound(t/n)' which tells the compiler
> > that for type t/n the inst `any' should be considered to be equivalent to a
> > bound inst i where i contains all the functors of the type t and each argument
> > has inst `any'.  This is required to allow us to represent HAL's `old' inst
> > using `any'.
> 
> Why not write out the `bound(...)' insts explicitly?

That's what the HAL compiler has done in the past, but it's not always
possible.  E.g. for a polymorphic predicate

	:- pred p(..., T::out(any)).

we want the `any' inst to be treated as `bound(...)' for some types and
`any' for others.

> 
> > In HAL, `old' is like `any' if the type is an instance of a
> > particular type class (`solver/1').  However, for types that are not instances
> > of `solver/1', `old' needs to be treated as though it is `bound'.
> 
> Does this mean that the mode system in HAL behaves differently depending on
> which type class instance declarations are in scope?

HAL requires the solver class instance for a type  to have the same scope
as the type: it must be defined in the same module as the type and if
the type is exported then the instance must also be exported.

> 
> > This change also provides a new Boolean option
> > `--default-any-is-bound' which, when set, assumes that `any' is
> > always equivalent to `bound', except for types t/n for which a `:-
> > pragma any_is_not_bound(t/n)' declaration exists.  We plan to use
> > this option when compiling HAL code because it allows us to use
> > existing non-solver types (e.g. types defined in the Mercury
> > standard library) without having to explicitly add a `:- pragma
> > any_is_bound' declaration for each type.
> 
> Compiler options that affect the language semantics should be avoided
> where possible.  I would rather make --default-any-is-bound be the
> default, and then there's no need for the compiler option or the
> `any_is_bound' pragma.

Okay.  That works well for us.

> As for the `any_is_not_bound' pragma, well, I don't really like the name.
> Also, I'd rather explicit syntax as part of the type declaration,
> rather than a separate pragma.  For example, perhaps something along
> the lines of `:- solver type ...' instead of `:- type ...'.

Okay, I'll do that.

An extension to this that we would like is for it to be possible to
declare an abstract type to be a solver type, but have its
implementation to be an ordinary "non-solver" discriminated union type
(or foreign type).  E.g.

	:- interface.
	:- solver type foo.

	:- implementation.
	:- type foo ---> ....

However, we probably want a special syntax for the implementation too,
e.g. something like

	:- solver_implementation type foo ---> ....

so that the compiler knows that the `solver' annotation hasn't just been
accidentally left off.

Oh, and another useful extension would be e.g.

	:- herbrand type foo ---> ....

which is equivalent to

	:- solver type foo ---> ....
	:- pragma reserve_tag(foo/0).

but perhaps I'll leave that for a later change.


David
-- 
David Overton                  Uni of Melbourne     +61 3 8344 1354
dmo at cs.mu.oz.au                Monash Uni (Clayton) +61 3 9905 5779
http://www.cs.mu.oz.au/~dmo    Mobile Phone         +61 4 0337 4393
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list