March 30, 2012
On 3/30/12 3:20 AM, Walter Bright wrote:
> There has been a trend in Phobos of having some truly gigantic modules.
> I believe this is indicative of a problem in the language. Andrei and I
> have talked about it, and we think it is because of difficulties in
> breaking a module up into submodules of a package.
>
> We think it's something we need to address.

Walter and I agreed on a design and I got tasked with writing a DIP. I don't have any time for it, but I had to do it so here it is:

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).


Thanks,

Andrei
March 30, 2012
Le 30/03/2012 16:24, Andrei Alexandrescu a écrit :
> On 3/30/12 3:20 AM, Walter Bright wrote:
>> There has been a trend in Phobos of having some truly gigantic modules.
>> I believe this is indicative of a problem in the language. Andrei and I
>> have talked about it, and we think it is because of difficulties in
>> breaking a module up into submodules of a package.
>>
>> We think it's something we need to address.
>
> Walter and I agreed on a design and I got tasked with writing a DIP. I
> don't have any time for it, but I had to do it so here it is:
>
> 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).
>
>
> Thanks,
>
> Andrei

Hi, It is an interesting proposal. You should start a thread about that so comment will not get lost in this one.
March 30, 2012
On 2012-03-30 14:52, Steven Schveighoffer wrote:

> Why would there be ambiguities? Unlike C include files, D modules are
> consistently compiled, unaffected by importing other modules.

What about static-if and string mixins?

-- 
/Jacob Carlborg
March 30, 2012
On 2012-03-30 16:17, Adam D. Ruppe wrote:
> On Friday, 30 March 2012 at 12:10:32 UTC, deadalnix wrote:
>> For the ease of distribution, you can use a module with public import
>> in it.
>
> There's still a few things I don't like though, about
> downloading and compiling several modules.
>
> When it is just one, you can download the single
> file and add it to your dmd command line.
>
> With several modules, that's more effort, either
> in downloading many things or in maintaining
> a zip+lib of them too.
>
> A lot different than my preference of "grab my cgi.d
> and play"!

That's way I'm working on a package manager.

-- 
/Jacob Carlborg
March 30, 2012
On 3/30/12 9:32 AM, deadalnix wrote:
> Le 30/03/2012 16:24, Andrei Alexandrescu a écrit :
>> On 3/30/12 3:20 AM, Walter Bright wrote:
>>> There has been a trend in Phobos of having some truly gigantic modules.
>>> I believe this is indicative of a problem in the language. Andrei and I
>>> have talked about it, and we think it is because of difficulties in
>>> breaking a module up into submodules of a package.
>>>
>>> We think it's something we need to address.
>>
>> Walter and I agreed on a design and I got tasked with writing a DIP. I
>> don't have any time for it, but I had to do it so here it is:
>>
>> 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).
>>
>>
>> Thanks,
>>
>> Andrei
>
> Hi, It is an interesting proposal. You should start a thread about that
> so comment will not get lost in this one.

Started a thread in the main forum.

Andrei
March 30, 2012
Le 30/03/2012 14:52, Steven Schveighoffer a écrit :
> On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> Le 30/03/2012 14:13, Steven Schveighoffer a écrit :
>>> On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <deadalnix@gmail.com>
>>> wrote:
>>>
>>>> I would expect this not to work, because bar isn't defined in module1
>>>> and template are supposed to use declaration scope, not instantiation
>>>> scope (unless it is mixin template).
>>>
>>> Right, I think it's the way it works now. But consider that the template
>>> instantiation *does* pull in some stuff from the instantiation scope
>>> (i.e. the template's module may not import the type being used to
>>> instantiate). I think it would be OK for the compiler to consider UFCS
>>> functions from the type's defining module as well, since you cannot
>>> instantiate the template for that particular type without having
>>> imported that module (i.e. it's guaranteed to instantiate the same no
>>> matter what module does it first).
>>>
>>> -Steve
>>
>> It does pull information from it's own scope and what is passed as
>> parameter. So it would still fail for the UFCS case.
>>
>> I don't see a clean solution for that, because of ambiguities. That
>> something that is not new and not specific to UFCS.
>
> Why would there be ambiguities? Unlike C include files, D modules are
> consistently compiled, unaffected by importing other modules. In order
> to instantiate a template templ!Foo, either the module that defines
> templ, or the module who is instantiating *must* import the module that
> defines Foo. Knowing this, the compiler should be able to deduce that it
> can consistently compile tmpl!Foo even if it pulls in UFCS functions
> from Foo's module or modules that Foo's module imports.
>
>> Immagine you want to define your own to!xxx() for your type xxx. (It
>> is dumb case because you have toString, but an interesting exercise
>> because for your own stuff, not something that is specified in the
>> language - like toString - the same could happen with no easy solution.
>
> I don't think this disproves anything. It should be possible without
> ambiguity given the rules I stated.
>
> -Steve

You are messing up everything.

First, this have NOTHING to do with UFCS. Second, current D import system have no ambiguity. But you propose to change that system. That would introduce ambiguity.

Even if you don't believe me, which is fine, it is safe to assume so unless you can prove otherwise.
March 30, 2012
On Fri, 30 Mar 2012 10:39:09 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-03-30 14:52, Steven Schveighoffer wrote:
>
>> Why would there be ambiguities? Unlike C include files, D modules are
>> consistently compiled, unaffected by importing other modules.
>
> What about static-if and string mixins?
>

This C code is what I'm talking about:

file1.h:

#define BLAH

file2.h:

#ifdef BLAH
int foo();
#else
char * foo();
#endif


main.c:

#include "file1.h"
#include "file2.h"

Note how including file1.h affects how file2.h is processed, with no control given to file2.h.  But in D this cannot happen, a module is consistently processed, no matter how it's imported or in what order.  Therefore you can be confident that no matter how it was imported, it has access to the same exact compiled code.

Neither static-if or string mixins cannot affect a file that does not import them (directly or indirectly).

-Steve
March 30, 2012
On Fri, 30 Mar 2012 10:48:04 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 30/03/2012 14:52, Steven Schveighoffer a écrit :
>> On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <deadalnix@gmail.com> wrote:
>>> Immagine you want to define your own to!xxx() for your type xxx. (It
>>> is dumb case because you have toString, but an interesting exercise
>>> because for your own stuff, not something that is specified in the
>>> language - like toString - the same could happen with no easy solution.
>>
>> I don't think this disproves anything. It should be possible without
>> ambiguity given the rules I stated.
>>
>> -Steve
>
> You are messing up everything.
>
> First, this have NOTHING to do with UFCS.

Yes it does.  The special rule only applies when using UFCS functions.

> Second, current D import system have no ambiguity. But you propose to change that system. That would introduce ambiguity.

Stating it doesn't prove it.  I claim no ambiguity, simply because I cannot see what the ambiguous case would be.  It's very easy to disprove me, show one example.

> Even if you don't believe me, which is fine, it is safe to assume so unless you can prove otherwise.

I'm not disputing the current module system is unambiguous.  I assert that my additions do not make it unambiguous.  Trying to prove that it's unambiguous would be really really hard, and require probably years of research.  I don't really want to prove it.

But disproving it can be done with one case.  If you believe it's ambiguous, you must have a case in mind, no?

-Steve
March 30, 2012
On 3/30/2012 4:24 AM, Piotr Szturmaj wrote:
> Walter Bright wrote:
>> I think it's far superior to the explicit friend thing in C++.
> Just curious. Did you take it from Delphi? :-)

No. I've never looked at Delphi in detail.

But in any case, for any language feature, there's always another language that had done it before, or something like it, or something that if you stand on one leg and touch your nose it resembles it, or whatever.

It's also true that good ideas tend to be reinvented over and over.

There have been many module systems before Delphi, too. I even have dim memories of reading about modules in the 1980 Ada spec :-)
March 30, 2012
On 3/29/2012 4:34 PM, Steven Schveighoffer wrote:
> But I realized after typing about 2 messages in response to this (and deleting
> them), you are right, there is a fundamental problem here. Because the template
> instantiation is based solely on the type. It does *not* include the type and
> whatever other modules you may have included that could define extension
> methods. I don't think it's an implementation issue, I think it's a design issue
> -- there simply is no way to do this.

Yes, you're right. The template is instantiated in the context of the template definition, not the template instantiation. Hence, unless the extension methods are in scope of the template definition, they will not be found.

I hadn't thought of this issue.


> So two possible sane rules:
> 1. A template instantiation can *only* use UFCS from functions defined in or
> imported from the module in which the template is defined. (i.e. the way it
> works now I think)

Yes, that is the way it works now.


> or
> 2. A template instantiation can *only* use UFCS from functions defined in or
> imported from the module in which the template is defined, *and* from functions
> as defined or imported by the module that defines the type on which UFCS is
> being used.

I would argue that:

3. An extension method for an argument of type template parameter T will be looked up only in the instantiation scope.