View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2012
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
Re: DIP16: Transparently substitute module with package
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
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home