[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!
  >