[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: module questions
Probably doable but analysis, analysis, ... -- Matthias
> X-Authentication-Warning: fast.cs.utah.edu: majordom set sender to owner-plt-scheme@flux.cs.utah.edu using -f
> From: Eli Barzilay <eli@barzilay.org>
> Content-Type: text/plain; charset=us-ascii
> Date: Sat, 29 Dec 2001 14:59:47 -0500
> Sender: owner-plt-scheme@fast.cs.utah.edu
> Precedence: bulk
> X-Virus-Scanned: by AMaViS snapshot-20010714
>
> On Dec 29, Matthew Flatt wrote:
> > A way around this problem would be a `require' form that gets only
> > non-syntax from some module, and where all imported names are listed
> > explicitly. In that case, it would not be necessary to consult the
> > imported module at all (until invocation time, to check that the named
> > variables are really exported).
> >
> > But for now, as we explore the balance between modules and units (just
> > as we continue to explore the balance between functions and objects),
> > leaving mutual recursion to units seems best.
>
> So, wouldn't it be correct to say that the basic reason you can get
> mutual dependencies with units is that they don't handle syntax? If
> this is true, then it looks like a good reason for allowing some form
> of non-syntax require...
>
> (BTW, wouldn't some implicit way look more elegant? -- like allowing
> such dependency if when tracing the modules there is no dependency
> cycle that involves exported syntax.)
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://www.barzilay.org/ Maze is Life!
>