This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: define-alias question
- From: Per Bothner <per at bothner dot com>
- To: Matthieu Vachon <matthieu dot o dot vachon at gmail dot com>
- Cc: "kawa at sourceware dot org list" <kawa at sourceware dot org>
- Date: Thu, 25 Jul 2013 00:05:09 -0700
- Subject: Re: define-alias question
- References: <CAOTvmokJvFFYkeCJPvD-VTmZNQ-n=S1v7AdyyTwyjDUQdbj3Vw at mail dot gmail dot com> <51E7900F dot 7060301 at bothner dot com> <19C6E9FB-A962-4830-8877-D662D89B34DB at theptrgroup dot com> <CAOTvmo=v0EDXx3cKhVMgEYrRZvciSSc89JqEmhoFm7LkJO+xGw at mail dot gmail dot com> <CAOTvmo=ohrijaGWfuXJQV8EQ=9uMhHOm4y=WnW2XLVPvzKeztw at mail dot gmail dot com>
On 07/21/2013 11:14 PM, Matthieu Vachon wrote:
When doing this, I thought about three possibilities to reduce the
work needed to convert current code, I even thought about a way to
keep BC. Here the ideas.
We introduce the ability to pass `#t` to `module-export`. I can then
see three ways for the behavior of this new feature:
1. We keep current behavior when no `module-export` is specified, but
`(module-export #t)` would export all declarations except
`define-alias`. We could then let the user specify symbols and `#t` so
it would be possible to export all declarations and export some or all
`define-alias` via explicit export (i.e. `(module-export #t alias-one
alias-two ...)`). This would be fully BC.
2. We change current behavior when no `module-export` is specified in
the way it is done in the attached patch, but we introduce
`(module-export #t)` that would do the old behavior, i.e. exporting
all even `define-alias` declarations. This is a language change.
3. We do a mix of 1 and 2. We still change current behavior when no
`module-export` is specified, `define-alias`. But we add a
`(module-export #t)` that will also NOT export `define-alias` but we
allow other symbols than `#t` so it's possible to export
`define-alias` explicitly. This is a language change.
I have a preference for #1, it keeps BC and and would use
`(module-export #t)` in my different modules. This would make it clear
that I want to export all declarations and since it would not export
`define-alias` by default, I would achieve my desire to use the same
`define-alias` in multiple modules without having clashes.
I don't know if this complication is worth it. As a matter of style,
using an explicit module-export is a good idea, at least if you're
writing a re-usable module. There can be a number of ways to define
exportable bindings: define, define-alias, define-syntax, define-unit,
define-class, define-namespace, ... Only plain define has a define-private
analog. I think the various forms of (module-export #t) make module-export
more complicated than it needs to be.
The advantage of the current default export behavior is that it is simple:
All names bound at top-level are exported. Scheme is a "Lisp-1" - there
is only a single namespace for both functions and variable. Arguably
aliases should not be treated differently - that would be a "Lisp-1.2".
I have the fear if we start tinkering with the default export list we'll
regret it. What if there is macro that may expand to define or
define-alias? Whether the name is exported would depend on the actual
macro-expansion in a possibly-non-intuitive way.
And of course the current behavior is the current behavior. A language
change (especially an incompatible change) needs some justification:
More "power", more concise code, consistency, compatibility with
standards or other implementations. I don't think changing the
default export set has enough justification.
After some more thought, I leaning towards the conclusion that this isn't
something Kawa needs to change.
Instead, maybe we should consider adding a define-private-alias form
(or define-alias-private).
Perhaps also we should consider less verbose forms of define-alias as
an import replacement. For example:
(define-alias [Map List] java.util:*)
as a short-hand for:
(define-alias Map java.util.Map)
(define-alias List java.util.List)
--
--Per Bothner
per@bothner.com http://per.bothner.com/