Walter Bright:

> You've already got it working with version, that's what version is for. Why add yet another way to do it?

Because I'd like something better. It's an idiom that I have used many times (around 15-20 times). I'd like the compiler (or build tool) to avoid me to specify two times what the main module is.

Also, the current way to do it, in those modules I have to specify the module name two times (once at the top and once at the bottom, unless I use some compile-time syntheses of the version identifier from the current module name).

Bye,
bearophile

On 5/1/14, 8:04 PM, Jason Spencer wrote:
> On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
>> I'll be blunt. What you say is technically sound (which is probably
>> why you believe it is notable)...
>
> Well, I suppose that's not the MOST insulting brush-off I could hope
> for, but it falls short of encouraging me to contribute ideas for the
> improvement of the language.

Sorry, and that's great. Thanks! -- Andrei

On 5/1/14, 8:04 PM, Jason Spencer wrote:
> On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
>> I'll be blunt. What you say is technically sound (which is probably
>> why you believe it is notable)...
>
> Well, I suppose that's not the MOST insulting brush-off I could hope
> for, but it falls short of encouraging me to contribute ideas for the
> improvement of the language.

I need to make an amend to this because indeed it's more than 2 std deviations away from niceness: I have a long history of ideas with a poor complexity/usefulness ratio, and I now wish I'd received such a jolt. -- Andrei

On Friday, 2 May 2014 at 14:59:50 UTC, Andrei Alexandrescu wrote:
> I need to make an amend to this because indeed it's more than 2 std deviations away from niceness: I have a long history of ideas with a poor complexity/usefulness ratio, and I now wish I'd received such a jolt. -- Andrei

I appreciate that, and can accept it in the spirit of mentoring and helpfulness.  What might work even better for me, though, is to forego the assumption that I need such a jolt or that you are the person, in this forum at least, to provide it and simply address the merits or lack thereof of the suggestion as made.

If we can't agree that a method, direct or indirect, to control the order of UTs is appropriate, then we should opt for the status quo.  By my reading of this thread, that leaves us with no consensus that UTs MUST be order-independent, but that being able to parallelize is a good thing.  It seems we can:

 1. leave defaults as they are and make parallelization an option, or
 2. make it the language model and allow people to dissent with an option

I can agree with Andre that you'd rather have a solid, well-defined language that works in most cases without too many buttons, switches, and levers.  I'm just not sure that jives with "easiest is safest" and "don't impose a model, provide a tool."  To me, improving the performance of a non-performance-critical aspect does not weigh enough to counterbalance a safety risk and model imposition.  How about others?

Test names seems pretty much agreed to.  I think the idea of making everything available to the druntime would let pretty much anyone do what they need.

On 5/2/2014 4:02 AM, bearophile wrote:
> Walter Bright:
>
>> You've already got it working with version, that's what version is for. Why
>> add yet another way to do it?
>
> Because I'd like something better. It's an idiom that I have used many times
> (around 15-20 times). I'd like the compiler (or build tool) to avoid me to
> specify two times what the main module is.
>
> Also, the current way to do it, in those modules I have to specify the module
> name two times (once at the top and once at the bottom, unless I use some
> compile-time syntheses of the version identifier from the current module name).

D has so many language features, we need a higher bar for adding new ones, especially ones that can be done straightforwardly with existing features.

On 1 May 2014 18:40, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 5/1/14, 10:32 AM, Brad Anderson wrote:
>>
>> It hasn't been C:\TEMP for almost 13 years
>
>
> About the time when I switched :o). -- Andrei

Amen to that!  (Me too)

On Monday, 5 May 2014 at 00:40:41 UTC, Walter Bright wrote:
> D has so many language features, we need a higher bar for adding new ones, especially ones that can be done straightforwardly with existing features.

Sure, but you'll have to agree that there comes a point where library solutions end up being so syntactically convoluted that it becomes difficult to visually parse.

Bad-practice non-sensical example.

    version(ParallelUnittests)
    const const(TypeTuple!(string, "name", UnittestImpl!SomeT, "test", bool, "result")) testTempfileHammering(string name, alias fun, SomeT, Args...)(Args args) pure @safe @(TestSuite.standard)
    if ((name.length > 0) && __traits(parallelizable, fun) && !is(Args) && (Args.length > 2) && allSatisfy!(isSomeString, args))
    {
        /* ... */
    }

Walter Bright:

> D has so many language features, we need a higher bar for adding new ones, especially ones that can be done straightforwardly with existing features.

If I am not wrong, all this is needed here is a boolean compile-time flag, like "__is_main_module". I think this is a small enough feature and gives enough back that saves time, to deserve to be a built-in feature. I have needed this for four or five years and the need/desire isn't going away.

Bye,
bearophile

On Mon, 05 May 2014 10:00:54 +0000
bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Walter Bright:
>
> > D has so many language features, we need a higher bar for adding new ones, especially ones that can be done straightforwardly with existing features.
>
> If I am not wrong, all this is needed here is a boolean compile-time flag, like "__is_main_module". I think this is a small enough feature and gives enough back that saves time, to deserve to be a built-in feature. I have needed this for four or five years and the need/desire isn't going away.

As far as I can tell, adding a feature wouldn't add much over simply using a version block for defining your demos. Just because something is done in python does not mean that it is appropriate for D or that it requires adding features to D in order to support it.

Though I confess that I'm biased against it, because not only have I never needed the feature that you're looking for, but I'd actually consider it bad practice to organize code that way. It makes no sense to me to make it so that any arbitrary module can be the main module for the program. Such code should be kept separate IMHO. And I suspect that most folks who either haven't done much with python and/or who don't particularly like python would agree with me. Maybe even many of those who use python would; I don't know.

Regardless, I'd strongly argue that this is a case where using user-defined versions is the obvious answer. It may not give you what you want, but it gives you want you need in order to make it so that a module has a main that's compiled in only when you want it to be. And D is already quite complicated. New features need to pass a high bar, and adding a feature just so that something is built-in rather than using an existing feature which solves the problem fairly simply definitely does not pass that bar IMHO.

I'm completely with Walter on this one.

- Jonathan M Davis

Jonathan M Davis:

> Just because something is done in
> python does not mean that it is appropriate for D or that it requires adding features to D in order to support it.

I agree. On the other hand now I have years of experience in both language and I still have this need in D.


> It makes no sense to me to make it so that
> any arbitrary module can be the main module for the program.

This feature is mostly for single modules, that you can download from archives, the web, etc. So it's for library code contained in single modules. In Python code is usually short, so in a single module you can implement many data structures, data visualization, data converters, etc. So it's quite handy for such modules to have demo, or even an interactive demo. Or they can be used with command lines arguments (with getopt), like a sound file converter. And then you can also import this module from other modules to perform the same operation (like sound file conversion) from your code. So you can use it both as a program that does something, and as a module for a larger system.


> Such code should be kept separate IMHO.

This means that you now have two modules, so to download them atomically you need some kind of packaging, like a zip. If your project is composed by many modules this is not a problem. But if you have a single module project (and this happens often in Python), going from 1 to 2 files is not nice. I have written tens of reusable D modules, and some of them have a demo or are usable stand-alone when you have simpler needs.


> Maybe even many of those who use python would; I don't know.

In Python is a very commonly used idiom. And there is not much in D that makes the same idiom less useful :-)

Bye,
bearophile