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

[Fergus Henderson]

On 18-Jul-2003, David Overton <dmo at cs.mu.OZ.AU> wrote:
> 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.

How common is that?
You could always use an inst cast in such situations.
Is the problem common enough that it's really worth
extending the language to solve it?

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

I guess that works.  But from a language design perspective,
I'd prefer to have the special semantics represented by special syntax,
rather than giving special semantics to a specific type class.

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

Yes.  The down side for us is that it's not ideal for backwards compatibility.
But existing code won't actually break, it just opens a loophole in the
mode system.  Also, existing code using `any' modes is probably very uncommon.
And fixing existing code is very simple (just add `solver' before the
type declarations of any solver types).

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

What's the difference in semantics between that and

 	:- interface.
 	:- solver type foo.
 
 	:- implementation.
 	:- solver type foo ---> ....

?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------