View mode: basic / threaded / horizontal-split · Log in · Help
December 21, 2012
About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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"
December 21, 2012
Re: About Go, D module naming
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.
December 21, 2012
Re: About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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.
December 21, 2012
Re: About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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
December 21, 2012
Re: About Go, D module naming
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home