[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A module question



    Date: 22-Mar-90  6:28:19 PST
    From: ramsdell%linus.mitre:ORG:Xerox
    
    In the Curtis/Rauen module proposal, what do non definitions within
    modules mean?  For example, what is printed by the following
    program?
    
    (interface a (value x))
    (interface b (value y))
    (module f ((exports a) (imports b) (open b))
      (define x 0)
      (set! x (+ x y)))
    (module g ((exports b) (imports a) (open a))
      (define y 0)
      (set! y (+ x y)))
    (display f#x)
    (display g#y)

I am amazed that we forgot to explain this in the paper.  Sigh.

The answer is that the semantics are a generalization of the R4RS
semantics, in which global bindings are initialized to some unspecified
values, the DEFINEs are turned into SET!s, and the resulting program is
evaluated from top to bottom.  Thus, in this case, the form

	(set! x (+ x y))

would be in error, referencing an as-yet unassigned binding.

A note on your example, though: modules do not have names in our
proposal, so the "f" and "g" in your code shouldn't be there.  The two
qualified names at the end should be a#x and b#y.
    
    Changing the subject, I would like to start a discussion on this
    module proposal by asking the following question.
    
      Ignoring meta-modules, what do you think about the idea of
      basing a module system on a simplification of the Mesa design?
      In particular, is the notion that modules should not be first 
      class controversial?
    
    In my opinion, modules should not be first class.
    John

Our opinion on this matter appears in the paper, of course.  We also
oppose first-class modules in the absence of strong typing since they
prevent any reasonable level of static checking of inter-module
references.  As a corollary to that, they seem in conflict with the
(important, to us) notion of explicit, textually-distinct specifications
of the interfaces between modules.

	Pavel

PS- I just got Jim's response to John's note.  I'm sending this out
anyway just to have two wordings available of essentially the same
answer.