Re: define-alias question

[Matthieu Vachon <matthieu dot o dot vachon at gmail dot com>]

Hi,

I attached a new patch that implements option #1 of my previous email.
This patch is fully backward compatible. I'm not sure it is the right solution
in the long term though, mainly in term of consistency of the language.

If you accept this patch, I will update the documentation.

For the implementation, I'm not sure I did it the right way. When there is
no module-export specified, how is it handled in Kawa? Is there a piece
of code somewhere exporting all declarations or is the default attributes
enough? Or maybe it's the contrary, when module-export is specified, all
non-exported declarations are made private?

Regards,
Matt

On Mon, Jul 22, 2013 at 2:14 AM, Matthieu Vachon
<matthieu.o.vachon@gmail.com> wrote:
> 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.v2.patch
Description: Binary data