[m-dev.] Submodule visibility rules

[Ralph Becket]

Fergus Henderson, Thursday, 11 July 2002:
> On 02-Jul-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > 
> > The compiler does complain if a client tries to use such things, but
> > doesn't prevent use of equivalence types defined in the submodule
> > interface that are synonyms for private parent types,
> 
> It should, if the submodule is exported.
> 
> i.e. the following module is not legal:
> 
> 	:- module m.
> 	:- interface.
> 		:- module sub.
> 		:- interface.
> 		:- type foo == bar.
> 		:- end_module sub.
> 	:- implementation.
> 	:- type bar ---> bar(int).
> 	:- end_module m.
> 
> If the compiler doesn?t report an errors for this module,
> then the compuiler should be changed so that it does so.

I get

	$ mmc --make m
	Making m.int3
	Making m.int0
	Making m.c
	Making m.o
	Making m:sub.o
	Making m
	** Error making `m'.
	m_init.o: In function `mercury_init':
	m_init.o(.text+0x2ae): undefined reference to `main_2_p_0'
	collect2: ld returned 1 exit status

Not good.

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