[m-dev.] types defined outside Mercury

Tyson Dowd trd at cs.mu.OZ.AU
Tue Feb 8 19:21:27 AEDT 2000


On 04-Feb-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Any opinions?

A quick summary of the outcome of a discussion on this topic:

Regarding hand defined types:

	- The traditional system of declaring "external" types is
	  to declare but not define a type.
	  Therefore checking for whether a type is abstract and
	  non-imported is equivalent to most cases of "hand defined".
	  This isn't true if the type is declared and defined, but the
	  definition is a lie (e.g. type_info/1 and bretheren).

	- The language reference manual doesn't mention that the
	  implementation section of a module doesn't *have* to give the
	  definition of all types named in the interface.

	- We may want to consider making it explicit when types are
	  external, the current system is error prone.
	  If it is explicit, it will be an experts only feature.

	- For the moment, we will use the traditional system, and
	  leave the explicit syntax as a possibility for a later date.

Other points:

	- Using c_pointer as
		:- type my_external_type ---> my_external_type(c_pointer).
	  is probably sufficient for most people writing external
	  interfaces.  We should probably document this trick (err, I
	  mean technique).

	- reflection.m is a good idea, but for backwards compatability
	  forwarding stubs will be left in std_util.m (and can be
	  delcared obsolete) so the implementation can be put into
	  reflection.m.

	- zs wants reflection.m to be very unstable for a while
	  (the code will be migrated first, than reflection will
	  probably be cleaned up a little, and have some types renamed
	  and interfaces redesigned)

	- it would be nice to be able to mark types as obsolete too
	  so we can mark std_util:type_info and type_ctor_info as
	  obsolete.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't eveyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list