X-Comment1: ############################################################# X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail # X-Comment4: # administrator to update your NRS & mailer tables. # X-Comment5: ############################################################# Mark Jones writes (not circulated to list): | Section 5.2.1, p.44: | ``It is a static error to have circular dependencies between imports/exports | using this naming convention. For example, the following is not allowed: | module X(Y..) where import Y; x=1 | module Y(X..) where import X; y=1'' | | Why is this restriction necessary? In this particular example, it doesn't | seem particularly useful since it will result in two modules, neither of | which exports anything. But in general, why not just follow the approach | described in 5.1.4 (paragraph at top of p.42) which gives the smallest | possible set of values satisfying the definition as its result? For | example, the declarations: | | module X(x,Y..) where import Y; x=1 | module Y(X..) where import X; y=1 | | would result in two modules, both of which export the value x (with original | name (X,x)). | | In addition, this restriction seems rather incompatible with the modid.. | syntax which is used in examples such as: | | module M(M..) where ... I agree with him. In any case, the compilation system is only meant to look at one module and its imported interfaces, in which case the static error specified here is not checkable. Furthermore, under this one-module-at-a-time constraint, it is quite clear what happens: when compiling X you export everything gotten from Y, and vice versa. Proposal: delete the paragraphs beginning "It is a static error..." from item 5 on page 44. Simon
