On Wed, Jun 07, 2017 at 12:41:03PM -0400, John Cowan wrote: > On Wed, Jun 7, 2017 at 9:28 AM, megane <megan...@gmail.com> wrote: > > If the module export list is not *, module-unexport-list is not used. In > > this case, it's enough to just remove the identifier to be unexported > > from the module-export-list. > > > > Very nice! > > While you are messing around with the module system, I'd like to see > "strip-prefix", which is just like "prefix" except it removes a prefix from > identifiers (if present) rather than adding one.
Both these proposals make me very very uneasy, for slightly different but somewhat related reasons. Warning: what follows turned into a long rant. Please bear with me. Unexport seems to me to be solving a non-problem. Exporting * always seemed questionable to me, since it is too implicit and very error-prone. It's very rare that you don't introduce *any* helper procedures or macros. In fact, introducing "unexport" just to paper over the problems that exporting everything creates seems like the wrong direction to me. But my more immediate concern is with proliferation of the magic set of special forms that's always available in a supposedly "empty" new namespace that a new module represents (the "initial macro environment"). In CHICKEN we have these: - import - import-for-syntax - reexport then there's these, which currently seem to be nicely put away in the "chicken" namespace in CHICKEN 4, but in CHICKEN 5 are initially available (might want to take a look at why that is...): - begin-for-syntax - import-syntax (WTF) - import-syntax-for-syntax (WTF) And "chicken" exports this in both chicken-5 and master: - export (which I always found rather useless, given that you have a list of exports right at the top already) Now we are discussing adding "unexport" onto that set. Ideally, the initial module environment should be empty. As in, completely void, a blank canvas. This allows for maximum flexibility in whatever the user wants to define inside the module. R7RS small avoids the problem of polluting the initial environment by strictly separating the library definitions from the Scheme code within it (the Scheme code must always be wrapped in (begin ...)). By doing this, R7RS allows for an almost infinitely extensible "library language", that will never pollute the Scheme module inside. Unfortunately, because it's not Scheme, this language isn't (easily?) programmable by the user. CHICKEN mixes up both things somewhat by having this initial macro environment. I'd prefer if we can avoid adding *any* new identifiers to this macro environment, to avoid stepping on the user's toes. So without a change in how the module language works I'd be against this change. FWIW, I think making this change is probably the Right Thing(TM), but also probably a too large change to do now, in CHICKEN 5. Regarding drop-prefix, it makes me uneasy because of the dual use of symbols and lists as library identifiers. In R7RS, again, you have an "import set" which is any of (only ...), (rename ...), (except ...) or (prefix ...) or a "library name", which is ALWAYS a list. So there's no ambiguity whatsoever: you can have a library called (rename file pattern) and it can always be distinguished from a rename of an identifier from a library, because "file" and "pattern" are not valid library names. In CHICKEN, we allow both "(file)" and "file" as a library name, so there's an ambiguity. With every new import option we add we make this problem worse. I would prefer us to reconsider allowing this duality by either going the R7RS route and requiring the identifier to always be a list, or dropping the list syntax altogether and only allowing symbols. Without this change, I'd be EXTREMELY hesitant to add any more import operators. Regarding the list syntax versus symbols, it would be easier on our users, porting-wise, to only allow symbols as library names. It also maps more clearly to the file system. Aesthetically and for compatibility with other Schemes, I'd prefer the list syntax only. But accepting both is (in hindsight) quite the mistake. We can still change things before it's too late... Cheers, Peter
signature.asc
Description: Digital signature
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers