Re: defer cyclic module import until XQuery 1.0

Michael Kay wrote:

> OK, sorry: I phrased it wrong. In XSLT, if module A explicitly includes
> module B, then B implicitly includes A, in the sense that everything in A
> becomes visible in B. Although the references between modules can't be
> cyclic, the references between templates and functions can. The essence of
> the point I was trying to make is that there's no restriction on mutual
> recursion between templates/functions in different modules.

OK.  However, XQuery has static binding of names *within* each module,
and we should be able to separately compile a library module.  In XSLT
you don't static name binding in the normal sense, and while you might
be able to do some kind of separate compilation it would have to leave
a lot of name binding until run-time.

Michael Rys wrote:
 > Note that there is a difference between C and XQuery in that C really
 > does not have modules but text copying includes. Modules provide some
 > form of information hiding.

I was thinking of each .c file as a module.  Two .c files can
reqursively reference definitions in each other.  And there is
information hiding between .c files.  Include files provide a (manual,
unenforced) machanism for "interface files".

 > PS: I think that all these questions about Modules should lead to
 > postponing the module import feature to the next version.

Either than, or some subset we're confident is well-defined, can be
easily implemented, and can be extended to the "all-dancing" module
system we want.

In that case, for the next version I'd lobby for my "local:" prefix
for non-exported definitions.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Wednesday, 3 March 2004 18:58:00 UTC