Re: define-alias question

[Per Bothner <per at bothner 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/