| ... | ... | @@ -29,6 +29,10 @@ This will not only make everything consistant, but allow seperate decisions on w |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
elements within a subordinate list will be intpreted as before, as either data constructors or class methods.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
see section 9 of the following paper for more details:
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -37,3 +41,14 @@ reference: |
|
|
|
|
|
|
|
|
|
|
|
- [ http://www.cse.ogi.edu/\~diatchki/hsmod/](http://www.cse.ogi.edu/~diatchki/hsmod/)
|
|
|
|
|
|
|
|
## Clarifications
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are a few things that should probably be clarified by the language definition dealing with field names and class methods, not that there is debate but they should be clearly specified:
|
|
|
|
|
|
|
|
|
|
|
|
1. does exporting a class name and a method name seperately as a function allow it to be declared in instance declarations? or does the function name need to be exported as part of a subordinate list?
|
|
|
|
|
|
|
|
1. the field name and function namespaces are different and export/import rules should take this into account, declaring fields creates _both_ a function and a field name. so should exporting the function also export the field name? or should the field name only be exportable via a subordinate list? |