[m-rev.] for review: automatically generate all type_ctor_infos on non C backends

[Fergus Henderson]

On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> On Fri, Nov 21, 2003 at 04:49:30AM +1100, Fergus Henderson wrote:
> > On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > On Thu, Nov 20, 2003 at 10:38:07PM +1100, Simon Taylor wrote:
> > > > Would making `ticket' a foreign type rather than an equivalence remove
> > > > some of the special casing?
> > >
> > > The snipped code that you deleted fixes the problem.
> > > 
> > > However the best solution in the long run would be to make everything
> > > builtin a foreign_type. 

The goal of "make everything builtin a foreign_type" is unachievable,
because there are an infinite number of different builtin tuple and
higher-order types.  You can't have an explicit foreign_type definition
for each of them.

> > > This would require adding a new annotation to
> > > the foreign_type which declared that there was only one representation
> > > for equal types to avoid the problems mentioned in the User Manual
> > > <http://tinyurl.com/vte6>.
> > 
> > Why?  What problem?  
> > 
> > Are you referring to these ones I've quoted below?
> > For a foreign type, those should not be a problem,
> > since there is no way to deconstruct a foreign type,
> > and trying to examine the representation of a foriegn
> > type using argument/3 and functor/3 _should_ raise an
> > exception, regardless of the determinism.
> > 
> >  | - If the program contains any deconstruction unification or switch on a
> >  |   variable of type T that could fail, other than unifications with mode
> >  |   `(in, in)', then it is a compile-time error.
> >  | 
> 
>     ( X = 0 ->
>         ...
>     ;
>         ...
>     )
> 
> I get a compiler error on the line "X = 0" when I define int as foreign
> type.

Ah, I see.  For a foreign type, there is normally no way to write such
a deconstruction, but of course that is not the case if you implement
one of the concrete builtin types (int, string, float, char, and tuples)
as a foreign type.

For these concrete builtin types, the Mercury compiler already needs to
know how to construct and deconstruct values of those types.
It also needs to know how to declare those types, since we don't want
it to pass them around as `MR_Box' like it does with foreign types.
So it would make sense for it to also just know that these types
are builtin and have only one representation, even if declared as foreign
types with user-defined equality.  There's no need to require any special
annotation on the foreign_type declaration.

For this approach, I think most of the code which currently calls
type_has_user_defined_equality_pred should be changed
to instead call a new predicate type_has_non_canonical_representation,
which would be the same as type_has_user_defined_equality_pred
except that it would not succeed for these concrete builtin types.

On the other hand, declaring these concrete builtin types as foreign types
is a bit of a lie.  For example, unlike all other foreign types, they must
not get passed around as MR_Box.  So I don't think it is a good idea to
do that.

If you really wanted to have an explicit definition for every type, I would
suggest a new form of definition

	:- type int is builtin.

but since that still wouldn't suffice for tuples and higher-order types,
I don't think it is worth the effort.

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