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

[David Overton]

On Fri, Jul 18, 2003 at 02:08:11PM +1000, Fergus Henderson wrote:
> > > 
> > > 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?

It's quite a common problem.  HAL-generated Mercury code contains lots
of inst casts.  This greatly complicates the HAL code generator and
makes the generated code hard to read and debug.  We are trying to move
towards removing the need for inst casts.  Hence my tinkering with the
Mercury mode system (but only in ways that I think improves 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.

Yes, I agree completely.  However, that's not the way HAL does it :-(

Anyway, the approach I've proposed for adding the required functionality
to Mercury doesn't suffer from this problem.

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

With the former, the type foo will appear to be a solver type from
outside the module, but just a normal type from within the module.
(i.e. outside the module `any' is different to `bound(...)', but inside
the module they are the same).  This is useful for implementing
constraint solvers using a ground representation.

With the latter case, the type foo is considered to be a solver type
inside the module as well.  This will most commonly be used for
"herbrand" types which use a reserved tag to represent `var'.

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