[Larceny-users] cyclic library dependency

[Sven Hartrumpf]

Hi all.

I am trying to compile R7RS libraries that contain a (direct) cyclic dependency.
If I use compile-stale from the shell, this enters a recursion running out of
mmap space.
compile-library from the REPL will not work either.
What else could work?

Any work-around appreciated.
(Except breaking the cycle in my code :-) )

Sven

[William D Clinger]

Post by Sven Hartrumpf
I am trying to compile R7RS libraries that contain a (direct) cyclic dependency.
If I use compile-stale from the shell, this enters a recursion running out of
mmap space.
compile-library from the REPL will not work either.
What else could work?
Any work-around appreciated.
(Except breaking the cycle in my code :-) )

I didn't think cyclic dependencies were allowed by the R7 library system.

I know cyclic dependencies aren't allowed by the R6 library system, and
I thought the R7 library system was supposed to have the same semantics
as the R6 system with a few features added and subtracted.

Will

[Alex Shinn]

Post by Sven Hartrumpf

Post by Sven Hartrumpf
I am trying to compile R7RS libraries that contain a (direct) cyclic

dependency.

Post by Sven Hartrumpf
If I use compile-stale from the shell, this enters a recursion running

out of

Post by Sven Hartrumpf
mmap space.
compile-library from the REPL will not work either.
What else could work?
Any work-around appreciated.
(Except breaking the cycle in my code :-) )

I didn't think cyclic dependencies were allowed by the R7 library system.

I'd have to double check, but I don't think we explicitly forbid them.
Nonetheless it's pretty much always indicative of a broken design,
and I wouldn't expect any implementation to support it. Chibi catches
this case and gives an explicit error.

I know cyclic dependencies aren't allowed by the R6 library system, and

Post by Sven Hartrumpf
I thought the R7 library system was supposed to have the same semantics
as the R6 system with a few features added and subtracted.

Basically yes - we don't have low-level macros or versions
so the semantics are vastly simpler, and we used a syntax
allowing for easy inclusion of existing R5RS code.

Where does R6RS state it forbids cyclic libraries?

[William D Clinger]

Post by Alex Shinn
Where does R6RS state it forbids cyclic libraries?

That's a consequence of R6RS Section 7.3, and is stated
a bit more directly in the (never-ratified) R6RS Rationale
Section 7.

What I'm about to quote is easier to understand if you recall
that, in the absence of macros, all variables are referenced
at phase 0. From R6RS Section 7.3:

If any of a library’s definitions are referenced at
phase 0 in the expanded form of a program, then an
instance of the referenced library is created for
phase 0 before the program’s definitions and
expressions are evaluated. This rule applies
transitively: if the expanded form of one library
references at phase 0 an identifier from another
library, then before the referencing library is
instantiated at phase n, the referenced library
must be instantiated at phase n.

Note the word "must" in that last sentence. Note also the
two uses of the word "before". If some library B imports
another library A, then the above says library A "must" be
instantiated "before" library B is instantiated.

A library can't be instantiated at level 0 before it is
instantiated at level 0, so cyclic library dependencies
are forbidden by the R6RS absolute requirement ("must")
quoted above.

The R6RS Rationale Section 7 says:

The library system does not address the following
goals, which were considered during the design
process:

* independent compilation
* mutually dependent libraries
* separation of library interface from library
implementation
* local modules and local imports

The only one of those four that is clearly forbidden by
an absolute requirement of the R6RS is the second one:
mutually dependent libraries.

Will

[Alex Shinn]

Thanks for the explanation Will, that makes sense.

It seems from the rationale that at least some authors
considered the possibility of cyclic libraries. That
combined with the loose, phase-free specification of
R7RS-small libraries makes me think we did the right
thing (though personally I'm strongly opposed to cyclic
dependencies).

R7RS-large will include low-level macros and by
necessity a specification of semantics regarding
phasing, and should therefore address this directly.
--
Alex

Post by William D Clinger

Post by Alex Shinn
Where does R6RS state it forbids cyclic libraries?

That's a consequence of R6RS Section 7.3, and is stated
a bit more directly in the (never-ratified) R6RS Rationale
Section 7.
What I'm about to quote is easier to understand if you recall
that, in the absence of macros, all variables are referenced
If any of a library’s definitions are referenced at
phase 0 in the expanded form of a program, then an
instance of the referenced library is created for
phase 0 before the program’s definitions and
expressions are evaluated. This rule applies
transitively: if the expanded form of one library
references at phase 0 an identifier from another
library, then before the referencing library is
instantiated at phase n, the referenced library
must be instantiated at phase n.
Note the word "must" in that last sentence. Note also the
two uses of the word "before". If some library B imports
another library A, then the above says library A "must" be
instantiated "before" library B is instantiated.
A library can't be instantiated at level 0 before it is
instantiated at level 0, so cyclic library dependencies
are forbidden by the R6RS absolute requirement ("must")
quoted above.
The library system does not address the following
goals, which were considered during the design
* independent compilation
* mutually dependent libraries
* separation of library interface from library
implementation
* local modules and local imports
The only one of those four that is clearly forbidden by
mutually dependent libraries.
Will