April 05, 2012
On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
> On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
> <michel.fortin@michelf.com> wrote:
>> Question 2: does std.algorithm.sort refer to the std.algorithm.sort
>> *module* or to std.algorithm.package.sort *function* publicly imported
>> from the std.algorithm.sort module?
>
> The function. A symbol that is not specified as the module name in
> import statement or in a module statement is always *not* a module. I
> think our one saving grace here is that when you want to import a
> specific symbol from a module, this is not the syntax:
>
> import std.stdio.writefln;
>
> So there is never any ambiguity as to whether you mean a module
> identifier or other symbol.

Interesting. But isn't there an ambiguity when the symbol is not the last one in the chain? Consider:

a.b.c.x

Could be static member d of class c in module a.b, or module member d in module a.b.c.


Andrei
April 05, 2012
On Thu, 05 Apr 2012 10:26:16 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
>> On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
>> No, public imports simply mean that you can view the publicly imported
>> module. It does *not* add aliases to the importing module.

[snip]

> I know. I think you answered too fast.
>
> I wasn't stating that public import are the same as what you propose. I was discussing the fact that both probably answer the same need and that 2 different syntax is something to avoid.
>
> Code wouldn't be broken in unexpected way, because thing will cause either a compile error (collision of names, but the problem exists with other solutions too) or is illegal in the current shape of the language.

My assertion above is 100% *WRONG*.  See this bug I just filed.  http://d.puremagic.com/issues/show_bug.cgi?id=7830

In fact public imports today are *exactly* the same as what I proposed. I had no idea.

I think we are (well, at least I am) on a wild goose chase here.  All that is left to discuss is if/how we want to allow importing of packages.

But I think DIP15 already covers that http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15

I think DIP16 is worksforme/invalid, and should be closed.

-Steve
April 05, 2012
On Thu, 05 Apr 2012 10:35:52 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
>> On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
>> <michel.fortin@michelf.com> wrote:
>>> Question 2: does std.algorithm.sort refer to the std.algorithm.sort
>>> *module* or to std.algorithm.package.sort *function* publicly imported
>>> from the std.algorithm.sort module?
>>
>> The function. A symbol that is not specified as the module name in
>> import statement or in a module statement is always *not* a module. I
>> think our one saving grace here is that when you want to import a
>> specific symbol from a module, this is not the syntax:
>>
>> import std.stdio.writefln;
>>
>> So there is never any ambiguity as to whether you mean a module
>> identifier or other symbol.
>
> Interesting. But isn't there an ambiguity when the symbol is not the last one in the chain? Consider:
>
> a.b.c.x
>
> Could be static member d of class c in module a.b, or module member d in module a.b.c.

Stop reading all my posts except for the ones I just posted.  I was completely wrong in what I thought the compiler couldn't do, because the spec is lacking.

I currently think DIP16 is invalid/worksforme (public imports allows splitting a module into a package).  All that is left is how we could specifically import a package with one import statement.

DIP15 covers that.  But I don't even think we need that, we can fix Phobos without any compiler changes.

-Steve
April 05, 2012
On Thu, 05 Apr 2012 10:33:14 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2012-04-05 11:46:38 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> I don't like this proposal, simply because this means one function/symbo l
>> per submodule.  It should be more flexible than that.  But I like the li ne
>> of thinking.
>
> I have the same reserve about it's lack of flexibility too. It would be a nice thing to have for all those libraries having one module per class as it'd reduce the length of the fully qualified name you have to use when you need to disambiguate.

I see the point you are going for.  I don't really like the one-class-per-module style as much as how phobos has one module per category.  But that's not an excuse not to examine this possibility.

I think it's a different issue than what DIP16/DIP15 is trying to solve.

> But for moving a module like std.algorithm to a package, it's cumbersome.

Not really.  Just move the files to another directory (i.e. std/internal/algorithm) and publicly import them.

>
>
>> Let's re-examine the issue.  We need to allow splitting of a module X.d
>> into pieces for maintenance (or possibly accessibility -- disallowing
>> friends).  But we don't want to break code which currently uses FQN to
>> access X's symbols.
>>  I think the following might work:
>>  algorithm.d:
>>  import this = std.algorithm_impl.sort;
>>  Which then imports std.algorithm_impl.sort, and effectively aliases all
>> its symbols into algorithm.d.  If std.algorithm_impl.sort defines a
>> function called sort, then it's also aliased to std.algorithm.sort.  In
>> essence, sort has *two* FQN, but there are no FQN that refer to more tha n
>> one symbol.
>
> This is what a public import should do.

I wasn't aware of this.  Mostly because the spec omits that feature.  I have to retract almost everything I've argued, because we already have the means to fix what I think DIP16 is trying to solve without any compiler changes.

-Steve
April 05, 2012
Le 05/04/2012 16:35, Andrei Alexandrescu a écrit :
> On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
>> On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
>> <michel.fortin@michelf.com> wrote:
>>> Question 2: does std.algorithm.sort refer to the std.algorithm.sort
>>> *module* or to std.algorithm.package.sort *function* publicly imported
>>> from the std.algorithm.sort module?
>>
>> The function. A symbol that is not specified as the module name in
>> import statement or in a module statement is always *not* a module. I
>> think our one saving grace here is that when you want to import a
>> specific symbol from a module, this is not the syntax:
>>
>> import std.stdio.writefln;
>>
>> So there is never any ambiguity as to whether you mean a module
>> identifier or other symbol.
>
> Interesting. But isn't there an ambiguity when the symbol is not the
> last one in the chain? Consider:
>
> a.b.c.x
>
> Could be static member d of class c in module a.b, or module member d in
> module a.b.c.
>
>
> Andrei

The whole point of this thread is to import symbols from submodules into a module. Obviously, this tends to create collisions. This one is hard to solve and should probably be an error.

However, such a collision will also appear with DIP16, and DIP16 cause also other type of collisions. So that one is superior - even if not perfect
April 05, 2012
Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
>> But for moving a module like std.algorithm to a package, it's cumbersome.
>
> Not really. Just move the files to another directory (i.e.
> std/internal/algorithm) and publicly import them.
>

std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good.

Plus, the package accessibility modifier would be broken with such a pattern.

The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better.
April 05, 2012
On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Starting a new thread from one in announce:
>
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
>
> Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks).
>
>
> Destroy!

BTW, this case makes the part of DIP16 which wants to shortcut fully qualified names invalid, or at least costly (I posted this code in another part of the thread, but I thought I'd bring it up higher).

The following is valid code today:

a/b.d:

module a.b;

void foo() {}
struct b
{
   static void foo() {}
}

main.d:
import a.b;

void main()
{
   a.b.foo();
}

If DIP16 were to be implemented, this becomes ambiguous.  Is a.b.foo() the module function foo() from a.b, or is it a shortcut for a.b.b.foo()?

The main issue is, because you can shortcut the FQN, and a chain of identifiers can have repeated identifiers in them, ambiguity is possible.

Michel Fortin pointed out at least three cases of this in phobos (although I can't see how they could be ambiguous, he has a good point).

-Steve
April 05, 2012
On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
>>> But for moving a module like std.algorithm to a package, it's cumbersome.
>>
>> Not really. Just move the files to another directory (i.e.
>> std/internal/algorithm) and publicly import them.
>>
>
> std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good.

import std.algorithm : sort;

BTW, this doesn't work today, I'll file a bug.

> Plus, the package accessibility modifier would be broken with such a pattern.
>
> The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better.

I don't really know what you mean, I didn't read that post.  Would you mind posting a link or repeating that argument?

-Steve
April 05, 2012
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
>>>
>>> Not really. Just move the files to another directory (i.e.
>>> std/internal/algorithm) and publicly import them.
>>>
>>
>> std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good.
>
> import std.algorithm : sort;
>
> BTW, this doesn't work today, I'll file a bug.

Nevermind, it works the same as if sort is defined in a std.algorithm module.  I'm kind of surprised the FQN doesn't work though...

-Steve
April 05, 2012
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix <deadalnix@gmail.com> wrote:
>> Plus, the package accessibility modifier would be broken with such a pattern.
>>
>> The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better.
>
> I don't really know what you mean, I didn't read that post.  Would you mind posting a link or repeating that argument?

Also, nevermind :)  I realize what you are talking about now.

This is a good point.  Of course, there are other mechanisms to do this, and DIP15 already proposes an improvement for this.

However, at least in the case of phobos, I don't think there's a lot of instances of package accessibility modifier.

-Steve