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: #############################################################
Yurgh. Still only 3 lines. I think the problem may be with the text
itself. Last try
Simon
============
Comments on John's comments.
| Type synonyms (in interfaces)
| ~~~~~~~~~~~~~
| Proposed: synomyms may (but need not) appear in interface type signatures;
| but if they do then the closure rule means that the synonym must be in scope
|
| This needs a little more cleaning up with respect to the closure
| constraint (5.1.3). Essentially, closure should deal only with
| `synonym free' types. The following should be legal:
| module Foo(x)
| type Bar = Int
| x = 1 :: Bar -- the interface can give the type of x as Int
I don't understand the problem. The closure rule only applies on *import*,
not *export*. For example
module Boo(T)
import W(X)
data T = C X
is fine. It exports T but not X. The *importer* on the other hand has
to import X by some other route (closure rule).
In the example you give it is certainly ok for Foo's interface to give
the type of X as Int.
So I propose not to change anything. If you think something needs to
be changed, could you give a precise proposal?
| Type synonyms (in import statements)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Proposed: allow only the T(..) form and NOT the T form, rather than the
| other way round, as at present. This is just a syntax change, but it
| enhances consistency.
|
| I don't agree at all with this. The (..) form suggests that T
| implicitly carries other names with it. This is not the case at all:
| the components of T must either come from outside the module or also
| be explicitly exported. Furthermore, a data type named by T may or
| may not be abstract; if it is, the (..) form seems to imply the
| existance of constructors:
|
| module M(T(..),U) where -- T would appear to export A and B
| data U = A | B
| type T = U
You could think of the (..) part as saying "including its definition",
or "including its right-hand side". Then in the example you give,
the T(..) says "T, including its right-hand side, = U", and all is clear.
I am attracted by the possibility of subsequently omitting the (..) to
gain abstraction over type synonyms.
What do others think?
| Hiding
| ~~~~~~
| Proposal: in hiding lists allow only the forms
| var
| T(..) -- Types
| C(..) -- Classes
|
| I assume T(c1,c2, ...) would also be legal
Just one more thing to check, so I suggest not. It seems defensible to
enumerate the constructors when they are being brought into scope, but
are you *really* going to do it when you are merely hiding them?
------- End of Forwarded Message
