defaulting.md

@@ -24,11 +24,21 @@ For replacement:
 
 - Perhaps require a default clause to name the class being defaulted over, as well as the type to choose.
 
+
+Other issues:
+
+
+- A default clause applies only within the module containing the declaration.  Defaults can be neither
+  exported nor imported.  Does anyone wish to propose import/export of defaults?
+
+  - For import/export: easier to propagate user-defined class defaults throughout a project
+  - Against import/export: a change in the imports of a module might silently change behavior
+
 ## proposal 1
 
 
 
-allow defaulting clauses of the following form
+Allow defaulting clauses of the following form
 
 
 ```wiki
@@ -36,38 +46,37 @@ default <classname> (type1,type2,type3,...)
 ```
 
 
-and the defaulting rule will take all class constraints and take the first unambiguous type that satisfies all the class constraints defaults.
+The defaulting rule will simply choose the first unambiguous type that satisfies all the constrained classes
+listed in the default decls.
 
 
 
-classes without defaults will have the equivalant of an empty type list, so defaulting will not occur.
+Classes without defaults will have the equivalent of an empty list of types, so defaulting will not occur.
 
 
 
-it is important to specify unambiguous because in the case of
+It is important to specify "unambiguous", because in the case of
 
 
 ```wiki
-
 default A (Int, String, ())
 default B (String, Int, ())
-
-
 ```
 
 
-the only valid default for a type in both classes should be () to avoid any issues arrising from order of interpretation of defaults.
+the only valid default for a type in both classes A and B should be ().  This avoids making an arbitrary choice based on
+textual ordering of the default declaration clauses.
 
 
 ### pro
 
 
 - very useful in interactive interpreter
-- less ad hoc than current method.
+- less ad hoc than current method
+- overcomes the Hat transformation problem
 
 ### con
 
 
 - can not exactly replicate behavior of existing defaulting mechanism, but can come close.
 - might hide errors, an optional warning on defaulting should be possible.
-- importing a module might silently change behavior (this can be mitigated if we only allow default definitons in the same module as the class is defined, but that takes away the ability to redefine defaults)