On Tue, Jul 4, 2017 at 10:11 AM, megane <[email protected]> wrote: Working with the export list is painful without some syntax support. You > end up repeating every identifier name otherwise. >
I consider the repetition to be a virtue rather than a vice. The whole purpose of modules is to control what identifiers are exposed to the outside world and what identifiers are private. If you want to expose everything, why bother with a module at all? Just have a plain file that is included rather than imported. Having an explicit export whitelist separates implementation from interface: the interface is whatever is exported, whereas the implementation can change freely, adding or removing non-exported procedures with no risk of affecting clients of the module in any way. How about a pair of syntax called export-all and export-none (or > similar). Every definition lexically after export-all up to a export-none > is exported and vice-versa. > That's the C++ style, and it works in that language because typically classes contain only declarations, not definitions. It would be very error-prone in the Scheme context; for example, if you wanted to refactor an exported procedure with a helper, you'd have to remember to bracket the helper with (export-none) and (export-all). Also, it is not Scheme style to have such hidden scope: if you wanted to do it so, you'd want (export-all <definition> ...) and (export-none <definition> ....). But if you want syntactic sugar, consider having exported-define, exported-define-syntax, etc. in Java style. -- John Cowan http://vrici.lojban.org/~cowan [email protected] Said Agatha Christie / To E. Philips Oppenheim "Who is this Hemingway? / Who is this Proust? Who is this Vladimir / Whatchamacallum, This neopostrealist / Rabble?" she groused. --George Starbuck, Pith and Vinegar
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
