On 20/03/2009 13:11, Mike Parker wrote:
> I understand what you were suggesting. My point is that in Java, which
> entry point to use is decided at run time, not compile time. From that
> perspective, it's a useful feature. For a statically compiled language
> like D, I don't see any obvious benefit. I mean, what is the benefit of
> this over delegating to a specific pseudo-main method based on a
> commandline arg or config file?

to add to what Ary and bearophile already said, that can be even more useful if it's combined with D's unittesting features. for example the main() could specify what unit-tests to run and in what order, provide the before & after code, etc..

bearophile wrote:
> Ary Borenszweig:
>> It is useful. Suppose you are writing a new module and want to test
>>  something quickly (not with unittests, maybe make a little program
>> to see how a specific feature you just wrote works). So you write a
>> main right there in the module, compile it and link it saying that
>> the main is in your new module. And you can then run it.

In a bigger project, this would result in quite a few main() functions, in several files. People tend to write them for debugging, and then forget to delete them.

> It has many usages, we have already discussed about this in the past.
> In D you can group related functions and classes into one module, so
> sometimes a module can be run alone (with the help of some modules it
> imports). So you can add demonstration code into its main, or
> benchmark/testing code, or module testing code, and so on. You can
> even create a program where certain modules can be sub-programs, that
> you can run alone to do specific sub-purposes, instead of using them
> as imported modules.

The other option would be to write the new mains in new files. This would not pollute the files for the Real Project. And with a naming convention (say, myfoomodule-test2-main.d but the real main file having the appname and no main part), it would then become easy to find, remove, or list all the "other" mains.

Also, having mymodule-main.d (and possibly mymodule-other-main.d) makes it possible to have an unlimited number of "mains", all without polluting the original mylib.

> Such usages are very common in Python too,
> there's even a idiomatic syntax to do such things.

That would go well with Python being interpreted, and "an easy" language.

> In the past other people and me have suggested some ways to do this.
> One of them was to add a __MAIN__ compile time constant defined as
> false for all the modules that the compiler is asked to not compile
> as the (main) module that contains the main(), so you can use a:
> static if (__MAIN__) { void main(string[] args) {...} } to wrap the
> main function. I don't remember if this very simple idea was already
> shot down or improved by better ideas.

I'd change "all the modules that the compiler is asked to not compile
as the (main)"

to "all the modules that the compiler is not asked to compile as the (main)".


Let's say multiple mains become legal. Then this __MAIN__ idea would at least give the programmer a chance to "point it out" in source code, that this is "just an auxiliary main".

> > dmd -c a.d
> > dmd -c b.d
> > dmd -c c.d
> > dmd a.obj b.obj c.obj --main=b.obj
> > 
> > in the above all three obj files have a main() method. this time it must be the *linker* that needs to understand the flag and only link the main() function into the executable. this requires changing the linker which is written in asm so less likely to happen.
> > 
> > I was not suggesting D to use a VM or the class-loader concept as in Java. even if we want that concept in D it needs to have a different implementation than in Java since there are problems with the way Java does this. (that's besides the differences due to the JVM)
> 
> I understand what you were suggesting. My point is that in Java, which entry point to use is decided at run time, not compile time. From that perspective, it's a useful feature. For a statically compiled language like D, I don't see any obvious benefit. I mean, what is the benefit of this over delegating to a specific pseudo-main method based on a commandline arg or config file?

I just asked what I thought was a very simple question. It was not intended to be the stimulus for vast changes! This newsgroup could do with some moderation. Wandering off the original topic is normal, not just common! All should bear in mind that unless this is just intellectual wanking we need to get this language stabilized.

Then others might start to take it seriously.

Georg Wrede:
>In a bigger project, this would result in quite a few main() functions, in several files. People tend to write them for debugging, and then forget to delete them.<

I meant them to be kept, and not deleted.

And big projects sometimes are made of sub-systems that are isolated enough to be sometimes useful alone.


>That would go well with Python being interpreted, and "an easy" language.<

To me now Python3 looks less simple than Java. It has now lot of features.

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

Steve Teale:

>All should bear in mind that unless this is just intellectual wanking we need to get this language stabilized.<

It will stabilize once it's appropriately dead and buried. Even Fortran and C aren't "stabilized" yet, see Fortran 2008 and C1x:
http://en.wikipedia.org/wiki/Fortran#Fortran_2008
http://en.wikipedia.org/wiki/C99#Future_standards_directions
Here I have seen more than once people talk about D3 and its possible AST macros ;-)

Bye,
bearophile

Reply to Steve,

> I just asked what I thought was a very simple question. It was not
> intended to be the stimulus for vast changes! This newsgroup could do
> with some moderation. Wandering off the original topic is normal, not
> just common!
> 

The the interesting threads are the OT ones. Particularly the OT regarding the subject line but still in CS.

This comes from the point that if some thing was on topic and interesting, I would have already looked into it. So the interesting things I don't know about are general OT.

Ary Borenszweig wrote:
> It is useful. Suppose you are writing a new module and want to test something quickly (not with unittests, maybe make a little program to see how a specific feature you just wrote works).

Why aren't you writing a unittest?

Well, you might only want to run the current module's tests, though in that case, you can compile the one module with -unittest and omit that for the others.

Steve Teale wrote:

> I just asked what I thought was a very simple question. It was not intended to be the stimulus for vast changes! This newsgroup could do with some moderation. Wandering off the original topic is normal, not just common! All should bear in mind that unless this is just intellectual wanking we need to get this language stabilized.
> 
> Then others might start to take it seriously.
> 

Discussions like this are precisely one of the strengths of this newsgroup. They sometimes lead to beneficial results, such as additions or changes to the language. The last thing we need here is moderation.