This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: define-alias question


Here attached a patch that implements explicit `define-alias` export.

While doing this, I had to add a `module-export` to `StreamsType.scm`
found in `kawa/slib` because it was relying on the fact that when no
`module-export` is specified, `define-alias` were implicitly exported
which is not the case anymore.

 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 gave a try at the `module-export #t` and was able to do it. Sole
problem I had was that I'm doing export of all declarations in
`Translator::finishModule` but at this point, we already have checked
for unused declarations so I have a bunch of warnings. I need to
export declarations before this validation is performed but I'm not
sure when this happens. It is done by `InlineCalls` but it's called
multiple times, so wasn't sure where to put my code so it is performed
before validation.

What do you think?

Matt

On Fri, Jul 19, 2013 at 12:51 PM, Matthieu Vachon
<matthieu.o.vachon@gmail.com> wrote:
>>
>> I have no problem with requiring an export statement, in fact I think I already do that in most of my code.  But I would be annoyed if it were impossible to export aliases.
>>
>
> I was a bit too "aggressive" with my first proposition. Removing
> ability to export
> aliases is not a good idea as you mentioned. Requiring an explicit export is a
> better alternative that brings in my opinion the best of both world.
>
> Ability to use `define-alias` like java imports without having bunch
> of warnings
> about already defined alias and ability to create dedicated aliases
> module where aliases are exported and can be reused by other modules.
>
> I'm going to propose a patch for this feature soon.
>
> Regards,
> Matt

Attachment: feature-explicit-alias-export.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]