Re: Circular Imports

On 11/15/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > I propose we add the following to handle this:
> >
> >    * In section 5.10 p:import, we need to define the resolved
> > location based on the 'href' attribute.  The 'href' attribute must
> > be resolved against the base URI of the p:import element.  The
> > resulting URI is the "resolved location" of the import.
>
> Hmm, not quite -- I think the "resolved location" is whatever your URI
> library comes back with as the location, so that redirects and conneg
> are allowed for.

If your library processor follows redirects, it will follow them every
time.  I still strongly believe that the resolved location should be the
result of resolving the 'href' attribute against the base URI.  That is a
consistent and well-defined algorithm.

We shouldn't  change that as a result of some protocol interaction whose
results may be temporary.

>
> So I think we agreed that this has to be expanded and changed a bit,
> along the following lines:
>
>  1) Do a 'minimal load' of every pipeline and pipeline library
>     document, by processing all p:imports, recording their resolved
>     locations, and declining to load anything twice;
>
>  2) Determine the type names *defined for export* by each top-level
>     scope == top-level pipeline or pipeline library == entry in the
>     resolved location table and every, as follows (see [1]):
>
>     a) The pipeline name itself, if the scope is a pipeline;
>     b) The step types and pipelines defined therein, if the scope is a
>        library.
>
>  3) Associate with every pipeline and library the resolved location of
>     all its imports, and from any of those which are libraries, the
>     resolved locations of all _their_ top-level imports, recursively.
>     That is, the transitive closure of p:import, _not_ descending into
>     p:pipeline.
>
>  4) Determine the type names visible within each library, as follows:
>
>     a) The step types and pipelines defined locally within the library;
>     c) The types _defined for export_ by all the resolved locations
>        identified for the library in (3) above.
>
>  5) Determine the type names visible (in addition to the builtins) in
>     each pipeline, as follows (see [1]):
>
>     a) The pipeline name itself;
>     b) The step types defined locally within the pipeline;
>     c) The types _defined for export_ by all the resolved locations
>        identified for the pipeline in (3) above;
>     d) The type names visible within its enclosing library, if it's in
>        one.

I agree with the above.

> This does more work than strictly necessary, and is liable to
> optimisation in the absence of circularity, but it's simpler to state
> w/o optimisation.
>
> On balance, I think this is too detailed to fit well in the
> spec. itself.  I think what we need in the spec., pbly in section 3.2,
> is [1] and something like this:
>
>   Circular and re-entrant chains of p:import are not errors, and
>   implementations MUST take the necessary steps, based on testing
>   string equality of the actual URIs involved (that is, after
>   absolutization and redirection, if any), to avoid infinite loops or
>   spurious duplicate-definition errors.  Appendix XXX provides
>   high-level description of one algorithm which does this.
>
> and then put the above 5-step story in (non-normative) Appendix XXX.

I agree.  Let's put this in an appendix and see what people think.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 10 January 2008 01:42:54 UTC