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

[John Cowan]

On Wed, Jun 7, 2017 at 4:07 PM, Peter Bex <address@hidden> wrote:

Unexport seems to me to be solving a non-problem.

As we discussed on IRC, I see unexport as mitigating the problems with

(export *), and it's better to drop exporting * instead.  "Whitelisting is better

than blacklisting."

 

- begin-for-syntax
- import-syntax (WTF)
- import-syntax-for-syntax (WTF)

I agree that these can be in a module.  Indeed, the only thing that absolutely

*must* be provided in the initial empty environment of a REPL is "import"

itself, as you have to import the "scheme" module (or some other base module)

in order to get going.

 

- export (which I always found rather useless, given that you have a
   list of exports right at the top already)

I never use the list of exports, but always "export".  That's partly because I'm

working in a style that accommodates Chicken and R7RS at the same time.

Unfortunately, because it's not Scheme, this language isn't (easily?)
programmable by the user.

Not programmable at all.  That was a deliberate choice to keep things

simpler for diverse Scheme implementations.

 

 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.

That's true, but frankly anyone who names a library (rename ...) or

(drop-prefix ...) deserves to lose. I haven't tested this, but I suspect at

least some R7RS handle such names by treating them as malformed

import qualifiers (i.e. errors) rather than library names.

 It's not like this set of names is going to be growing forever, either.

There is already support for drop-prefix in Chibi and Chez at least,

and I have not heard of any system allowing any other qualifier.

I can imagine some new things, like "(import (silently b))" where

any conflicts with existing modules are silently overridden, but they

wouldn't be fit for standardization for a long time, if ever.

 

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

I think it's quite convenient to accept both, and often wish that

R7RS systems would do this for ad hoc libraries.  I also find

Chicken's file-mapping convention (with dots) superior to

most systems, which map (foo bar) to foo/bar.  Chibi adopts

this strategy for the command line only:  in code you must

say "(import (foo bar baz))" but on the command line you

say "-m foo.bar.baz".  This works well for me.

What happens if you have an export list that includes both a prefixed
identifier and the same unprefixed identifier?  [...] 

Chibi warns if you do this, the same as if you import an identifier

from two different modules.  I'm not sure about Chez.

  

  Perhaps a saner approach is to only ever import
identifiers that actually have the prefix.

I wouldn't be opposed to that except that we have two precedents

for importing all the identifiers.

 

-- 

John Cowan          http://vrici.lojban.org/~cowan        address@hidden

All Gaul is divided into three parts: the part that cooks with lard and goose

fat, the part that cooks with olive oil, and the part that cooks with butter.

  --David Chessler