chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: megane
Subject: Re: [Chicken-hackers] [PATCH] Add unexport form for modules
Date: Thu, 08 Jun 2017 10:39:45 +0300
User-agent: mu4e 0.9.18; emacs 24.4.1

Peter Bex <address@hidden> writes:

> 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.

The only reason I'm using * export is to export is structs. That is,
automatically exporting all defines created by a defstruct call. I
already have a wrapper for defstruct, so maybe I should just export all
identifiers from there.

Maintaining the export list by hand is just busywork to me. So I only
use either empty export list or *.

Nice thing about empty export list + export or * + unexport is that you
can conditionally export all identifiers for e.g. unit testing.

>
> 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").

[...]

Why not just move all the module syntax to a new library? You currently
have to have '(import chicken scheme)' in the beginning anyways.
Wouldn't be a big deal if you had to add module-syntax and
module-syntax-yolo there as well.

> 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.

I don't like this drop-prefix because that would make editor support
harder. Say you want to look-up documentation for an identifier. With
drop-prefix the editor would have to understand the import statement and
go looking for the identifier for all modules for which you had used
drop-prefix. OK, not a big problem, and applies to the current rename
facility as well.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]