Re: [Scheme-reports] library at file level (was: Ratification vote for R7RS Small) John Cowan (13 May 2013 14:19 UTC)
(missing)
Re: [Scheme-reports] library at file level Per Bothner (13 May 2013 16:54 UTC)
Re: [Scheme-reports] library at file level Andy Wingo (15 May 2013 19:05 UTC)
Re: [Scheme-reports] library at file level John Cowan (15 May 2013 19:14 UTC)
Re: [Scheme-reports] library at file level taylanbayirli@gmail.com (15 May 2013 20:12 UTC)
Re: [Scheme-reports] library at file level John Cowan (15 May 2013 21:07 UTC)

Re: [Scheme-reports] library at file level (was: Ratification vote for R7RS Small) John Cowan 13 May 2013 14:19 UTC

Sam TH scripsit:

> This is simply incoherent. If macros can be defined by procedures,
> then mutually recursive libraries each of which export macros cannot
> be sensibly expanded.  What does your system do in this case?

It actually isn't incoherent, provided the recursion is indirect and the
compiler can process both libraries simultaneously.  Thus suppose that
library (a) defines procedures aproc and aaux and macro amac, and library
(b) defines procedures bproc and baux and macro bmac.  It is perfectly
intelligible for aproc to be defined using bmac, which is defined using
baux, and bproc to be defined using amac, which is defined using aaux.
The two libraries must import each other, which is banned by R6RS;
what is more, probably most compilers can't handle this because they
only compile one library at a time.

Similarly:  In Java, classes A and B cannot mutually extend each other,
but A can have an inner class that extends B and B can have an inner
class that extends A.  Attempting to compile either, at least with
the Oracle/Sun compiler, will compile both simultaneously.  In Ada,
two generic packages can recursively instantiate each other, provided
the actual points of recursion are not mutual.

If it comes to that, a procedure can't depend on a macro that depends
on the self-same procedure, either.

--
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
If he has seen farther than others,
        it is because he is standing on a stack of dwarves.
                --Mike Champion, describing Tim Berners-Lee (adapted)

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports