[Top][All Lists]

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

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

From: John Cowan
Subject: Re: [Chicken-hackers] [PATCH] Add unexport form for modules
Date: Thu, 8 Jun 2017 13:29:48 -0400

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

reply via email to

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