An article about many of the design decisions behind the Go language. It's an excellent article even if you don't agree with some of those decisions:

http://talks.golang.org/2012/splash.article

I suggest all people interested in language design to read that article. Go is a simple language after all, so that page is never hard to understand.

One group of Go design decisions is about the strictness of its module system. One example of such strictness is that unused imports are a compilation error! (Another example is that Go module system does not allow cycles, and this is enforced both at compiler and linker level.)

Recently the good Andrej Mitrovic has closed this old diagnostic bug report of mine, marking it as dupe of another issue:

http://d.puremagic.com/issues/show_bug.cgi?id=3972


The bug report presents a case, composed of two modules:


-------------

// File name: foo.d
module bar;
enum int x = 10;

-------------

// File name: spam.d
module test;
import foo: x;
void main() {}

-------------


After the patch by Andrej Mitrovic dmd is expected to generate a longer and more refined error message:

spam.d(2): Error: module bar from file foo.d must be imported as module 'bar'


Is this error message meaning that the correct spam.d is like this?


// File name: spam.d
module test;
import bar: x;
void main() {}


But how can dmd/rdmd know the file name of the "bar" module if it's written no where? I guess they can't, so you have to give them the file name manually to the compiler, in some way.

I don't like all this. After almost three years since that bug report I still think that letting D accept module names different from their file names is a mess, it's a "flexibility" (as Walter said in an answer) mostly useful to confuse programmers. A price paid by everyone for few special situations.

That nice article about the Go language shows that in the long run and for larger projects a little bit more strictness is a better decision. Think having a large D project with 2000 or 20000 modules, where module names are randomly different from their file names.

If that naming flexibility Walter talks about is so essential, then I suggest to introduce a special way to get it without allowing in the general case module names to differ from their file names.

Bye,
bearophile

On Friday, 21 December 2012 at 01:25:00 UTC, bearophile wrote:
> That nice article about the Go language shows that in the long run and for larger projects a little bit more strictness is a better decision. Think having a large D project with 2000 or 20000 modules, where module names are randomly different from their file names.
>
> If that naming flexibility Walter talks about is so essential, then I suggest to introduce a special way to get it without allowing in the general case module names to differ from their file names.
>
> Bye,
> bearophile

I've not yet ever thought about naming a module different than the file name. I suppose such a thing can come in handy but I'm not sure how as it would make finding your modules more difficult as was stated. I wonder if anyone does rename their modules differently than the files?

--rt

On Friday, 21 December 2012 at 01:25:00 UTC, bearophile wrote:
> I don't like all this.

I *love* all this. It's very useful for various compile time config features. You can swap out modules on the command line and things just work.

Even in Go, the package path doesn't have to match the filesystem path. "The meaning of "path" is not specified by the language, but in practice and by convention it is the slash-separated directory path of the source package in the repository"

On 12/20/2012 6:41 PM, Adam D. Ruppe wrote:
> On Friday, 21 December 2012 at 01:25:00 UTC, bearophile wrote:
>> I don't like all this.
>
> I *love* all this. It's very useful for various compile time config features.
> You can swap out modules on the command line and things just work.

There'd also be a revolt here if circular importing were removed.

Walter Bright:

> There'd also be a revolt here if circular importing were removed.

I didn't ask for the removal of circular importing. (But I suggest to read the rationale of the Go designers.)

Bye,
bearophile

On 12/20/12 10:06 PM, bearophile wrote:
> Walter Bright:
>
>> There'd also be a revolt here if circular importing were removed.
>
> I didn't ask for the removal of circular importing. (But I suggest to
> read the rationale of the Go designers.)

I did read the piece and found it surprisingly weak. The problems with C's modularity are misidentified. The entire discussion on include guards is irrelevant because it's been obsoleted by today's compilers, which trivially recognize include guards. The problem of bloated includes in C and C++ does exist but its causes are different.

Then, the approach to simplifying smacks of making the lives of the implementer easier while passing the buck to the user.


Andrei

On 12/20/2012 8:06 PM, Andrei Alexandrescu wrote:
> On 12/20/12 10:06 PM, bearophile wrote:
>> Walter Bright:
>>
>>> There'd also be a revolt here if circular importing were removed.
>>
>> I didn't ask for the removal of circular importing. (But I suggest to
>> read the rationale of the Go designers.)
>
> I did read the piece and found it surprisingly weak. The problems with C's
> modularity are misidentified. The entire discussion on include guards is
> irrelevant because it's been obsoleted by today's compilers, which trivially
> recognize include guards. The problem of bloated includes in C and C++ does
> exist but its causes are different.
>
> Then, the approach to simplifying smacks of making the lives of the implementer
> easier while passing the buck to the user.

Other issues:

1. Error for unused imports. This can be extremely irritating if you're trying to find the source of a bug by commenting out swaths of code. Also, Go doesn't have conditional compilation, another large source of irritation if unused imports are errors.

2. Name for module must match file name. Again, a nuisance if you're trying to rearrange code looking for a problem. If you want to always have the module name match the file name, just omit the module statement.


> That nice article about the Go language shows that in the long run and for larger projects a little bit more strictness is a better decision.

It makes a claim, it does not show it.

D has an excellent module system. No, I don't think Go or anyone else has a better one.

On Friday, 21 December 2012 at 02:41:38 UTC, Adam D. Ruppe wrote:
> I *love* all this. It's very useful for various compile time config features. You can swap out modules on the command line and things just work.

OK, I hadn't thought of that possibility.

I suppose to find modules not named the same as their host file, you can just perform a search on "module path.name" and it would be good enough.

--rt

On Friday, 21 December 2012 at 05:42:04 UTC, Walter Bright wrote:
> On 12/20/2012 8:06 PM, Andrei Alexandrescu wrote:
>> On 12/20/12 10:06 PM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> There'd also be a revolt here if circular importing were removed.
>>>
>>> I didn't ask for the removal of circular importing. (But I suggest to
>>> read the rationale of the Go designers.)
>>
>> I did read the piece and found it surprisingly weak. The problems with C's
>> modularity are misidentified. The entire discussion on include guards is
>> irrelevant because it's been obsoleted by today's compilers, which trivially
>> recognize include guards. The problem of bloated includes in C and C++ does
>> exist but its causes are different.
>>
>> Then, the approach to simplifying smacks of making the lives of the implementer
>> easier while passing the buck to the user.
>
> Other issues:
>
> 1. Error for unused imports. This can be extremely irritating if you're trying to find the source of a bug by commenting out swaths of code. Also, Go doesn't have conditional compilation, another large source of irritation if unused imports are errors.
>

Actually it does have one, it is part of Go's toolchain.

Go developers favor the way I advocate to write portable C and C++ code.

No preprocessor, instead create OS/Compiler specific files for the platform, for example:

btree.c
btree_windows.c
btree_linux.c
btree_solaris.c

The toolchain will then pick all required files depending on your target architecture.

The less one uses the preprocessor the better, specially when working in code that outlives programmers. Personally I hate #ifdef hell.

As for the other points, you're right.

--
Paulo

On 12/21/2012 06:41 AM, Walter Bright wrote:
> ....
>
> D has an excellent module system.

... modulo the private symbol clash issue. For all I know it is deliberate, which is embarrassing. Other than obviously breaking modularity, it severely restricts the usefulness of symbol disambiguation (which it makes necessary when it should not be), because the disambiguating alias may introduce more conflicts even if it is private, all over the code base.

Eg:

https://github.com/D-Programming-Language/druntime/pull/298#discussion_r1691013

> No, I don't think Go or anyone else has a better one.

Other languages that support modules usually get hiding of private symbols (or equivalent) right.