reddit discussion about Go turns to D again

[Jonathan M Davis]

On 2011-05-15 19:59, Andrei Alexandrescu wrote:
> On 05/15/2011 09:17 PM, Jonathan M Davis wrote:
> > On 2011-05-15 17:20, Andrei Alexandrescu wrote:
> >> On 05/15/2011 07:11 PM, dsimcha wrote:
> >>> On 5/15/2011 8:06 PM, Andrei Alexandrescu wrote:
> >>>> The function signatures would be identical underlying the fact that
> >>>> their actual semantics are identical.
> >>>> 
> >>>> Andrei
> >>> 
> >>> Not so sure. For parallel computation, you'd probably want to have some
> >>> additional, though optional, configurability for things like work unit
> >>> size.
> >> 
> >> Sure. Those are not per call call though. std.algorithm offers a ton of
> >> functions. The cleanest way to expose parallel equivalents is as
> >> functions with identical signatures in a different module. It's very
> >> much in the spirit of D.
> >> 
> >> We should take a look at Gnu parallel.
> >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html, which
> >> does the same (and I think they made the right decision).
> > 
> > The problem is that then you have name-clashes galor. If you ever import
> > std.algorithm and std.parallel_algorithm in the same module (which is
> > very likely to happen, I expect), then you're either going to have to
> > use aliases all over the place, or give the whole module name for
> > std.algorithm and std.parallel_algorithm with most function calls.
> 
> import std.algorithm;
> static import std.parallel_algorithm;
> 
> That uses stuff in std.algorithm by default, and stuff in
> std.parallel_algorithm on demand. Perfect.

I don't know about perfect. You still have the problem of conflicting names 
and being forced to fully specify them in many cases. It may work well enough 
though to justify giving them the exact same names, particularly given the 
benefits of possibly automatically replacing calls to std.algorithm with calls 
to std.parallel_algorithm (and vice versa) by changing the imports as well as 
making it obvious that the functions do essentially the same thing by having 
exactly the same names. However, you then have the problem of it being harder 
to know whether you're dealing with functions from std.algorithm or 
std.parallel_algorithm when reading code. A look at the imports will tell you, 
but it would still be easier with separate names.

So, I'm a bit divided on the matter. However, I think the primary issue here 
is that we be aware of what the pros and cons are of naming the parallel 
functions with exactly the same names as their serial counterparts, and name 
clashes are generally a major con. But if the pros outweigh the cons, then it 
makes sense to give them the same names. We already have several name clashes 
in Phobos (primarily between std.string and std.algorithm), and they're always 
annoying to deal with, so I'm generally biased against name clashes, but the 
module system is definitely designed to allow them and to give us the tools to 
get around the issues caused by them.

I had forgotten about static imports though, so thanks for the reminder about 
them.

- Jonathan M Davis