Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Tue, Jul 4, 2017 at 10:11 AM, megane <address@hidden> 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        address@hidden

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