On Wed, Jun 7, 2017 at 4:07 PM, Peter Bex <[email protected]> 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 [email protected] 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
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
