www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No -c no main()

reply Steve Teale <steve.teale britseyeview.com> writes:
Would it be a big deal to make the compiler recognize that there is no -c, but
no instance of main() has been found, and say

"Link skipped - no main()"

instead of what you get if you do dmd mian.d on

import std.stdio;

void mian()
{
   writefln("Hello Wolrd");
}
Mar 19 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Steve Teale wrote:

 Would it be a big deal to make the compiler recognize that there is no -c, but
no instance of main() has been found, and say
 
 "Link skipped - no main()"
 
 instead of what you get if you do dmd mian.d on
 
 import std.stdio;
 
 void mian()
 {
    writefln("Hello Wolrd");
 }


main might be linked in from another library/object on the command line.

dmd stuff.d unittest_main_stub.obj

You'd have to have the compiler crack open all .lib and .obj files and
look for a main.

  -- Daniel
Mar 19 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Daniel Keep Wrote:


 
 
 Steve Teale wrote:

 Would it be a big deal to make the compiler recognize that there is no -c, but
no instance of main() has been found, and say
 
 "Link skipped - no main()"
 
 instead of what you get if you do dmd mian.d on
 
 import std.stdio;
 
 void mian()
 {
    writefln("Hello Wolrd");
 }


 
 main might be linked in from another library/object on the command line.
 
 dmd stuff.d unittest_main_stub.obj
 
 You'd have to have the compiler crack open all .lib and .obj files and
 look for a main.
 
   -- Daniel


True, but maybe if there were only .d files?
Mar 19 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
It's a good idea. Please add to bugzilla as an enhancement request!
Mar 19 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 19/03/2009 12:19, Walter Bright wrote:

 It's a good idea. Please add to bugzilla as an enhancement request!


another thing that can be done is provide a compiler flag to specify the 
module that contains main() so the compiler will use that specific main 
and ignore all others. this is similar to how you specify the class with 
main() method in Java. Jar files have a manifest with this info and in 
Eclipse you specify the class in the Run dialog. I don't remember how it 
works with the command line (actually, I don't remember ever using the 
command line with Java)
Mar 19 2009
parent reply Mike Parker <aldacron gmail.com> writes:
Yigal Chripun wrote:

 On 19/03/2009 12:19, Walter Bright wrote:

 It's a good idea. Please add to bugzilla as an enhancement request!


 
 another thing that can be done is provide a compiler flag to specify the 
 module that contains main() so the compiler will use that specific main 
 and ignore all others. this is similar to how you specify the class with 
 main() method in Java. Jar files have a manifest with this info and in 
 Eclipse you specify the class in the Run dialog. I don't remember how it 
 works with the command line (actually, I don't remember ever using the 
 command line with Java)


It's not something that happens at compile time. All existing main 
methods are compiled into their respective class files. From the command 
line, you execute the JRE (java or javaw in Sun's case) and pass it the 
name of the class you want to execute. If the class has a main method, 
it is called. If not, you get an error.
Mar 19 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Mike Parker Wrote:


 Yigal Chripun wrote:

 On 19/03/2009 12:19, Walter Bright wrote:

 It's a good idea. Please add to bugzilla as an enhancement request!


 
 another thing that can be done is provide a compiler flag to specify the 
 module that contains main() so the compiler will use that specific main 
 and ignore all others. this is similar to how you specify the class with 
 main() method in Java. Jar files have a manifest with this info and in 
 Eclipse you specify the class in the Run dialog. I don't remember how it 
 works with the command line (actually, I don't remember ever using the 
 command line with Java)


 
 It's not something that happens at compile time. All existing main 
 methods are compiled into their respective class files. From the command 
 line, you execute the JRE (java or javaw in Sun's case) and pass it the 
 name of the class you want to execute. If the class has a main method, 
 it is called. If not, you get an error.


Java's model is complicated. it has the concept of class-loaders. 
What I'm suggesting is this: 
given three modules a,b and c all defining the main() function, you can do the
following:
dmd a.d b.d c.d --main=b.d 
currently the compiler will complain about multiple definitions of main(), but
with the above flag, it could skip over the main() functions in a and c. 

the next logical step would be to allow:
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)
Mar 19 2009
parent reply Mike Parker <aldacron gmail.com> writes:
Yigal Chripun wrote:

 Mike Parker Wrote:
 

 Yigal Chripun wrote:

 On 19/03/2009 12:19, Walter Bright wrote:

 It's a good idea. Please add to bugzilla as an enhancement request!


 another thing that can be done is provide a compiler flag to specify the 
 module that contains main() so the compiler will use that specific main 
 and ignore all others. this is similar to how you specify the class with 
 main() method in Java. Jar files have a manifest with this info and in 
 Eclipse you specify the class in the Run dialog. I don't remember how it 
 works with the command line (actually, I don't remember ever using the 
 command line with Java)


 It's not something that happens at compile time. All existing main 
 methods are compiled into their respective class files. From the command 
 line, you execute the JRE (java or javaw in Sun's case) and pass it the 
 name of the class you want to execute. If the class has a main method, 
 it is called. If not, you get an error.


 
 Java's model is complicated. it has the concept of class-loaders. 
 What I'm suggesting is this: 
 given three modules a,b and c all defining the main() function, you can do the
following:
 dmd a.d b.d c.d --main=b.d 
 currently the compiler will complain about multiple definitions of main(), but
with the above flag, it could skip over the main() functions in a and c. 
 
 the next logical step would be to allow:
 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?
Mar 20 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Mike Parker escribió:

 Yigal Chripun wrote:

 Mike Parker Wrote:


 Yigal Chripun wrote:

 On 19/03/2009 12:19, Walter Bright wrote:

 It's a good idea. Please add to bugzilla as an enhancement request!


 another thing that can be done is provide a compiler flag to specify 
 the module that contains main() so the compiler will use that 
 specific main and ignore all others. this is similar to how you 
 specify the class with main() method in Java. Jar files have a 
 manifest with this info and in Eclipse you specify the class in the 
 Run dialog. I don't remember how it works with the command line 
 (actually, I don't remember ever using the command line with Java)


 It's not something that happens at compile time. All existing main 
 methods are compiled into their respective class files. From the 
 command line, you execute the JRE (java or javaw in Sun's case) and 
 pass it the name of the class you want to execute. If the class has a 
 main method, it is called. If not, you get an error.


 Java's model is complicated. it has the concept of class-loaders. What 
 I'm suggesting is this: given three modules a,b and c all defining the 
 main() function, you can do the following:
 dmd a.d b.d c.d --main=b.d currently the compiler will complain about 
 multiple definitions of main(), but with the above flag, it could skip 
 over the main() functions in a and c.
 the next logical step would be to allow:
 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?


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.

If you couldn't do that you'd have to search for your only main in your 
project, change it by adding the necessary imports, compile it and run 
it. Way more steps.

Also, that way each module can have a main method that shows some of 
it's funcionality with a little program.
Mar 20 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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.


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.
Such usages are very common in Python too, there's even a idiomatic syntax to
do such things. 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.

Bye,
bearophile
Mar 20 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
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".
Mar 20 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
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.
Mar 20 2009
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
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..
Mar 20 2009
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
 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.
Mar 20 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Mar 20 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
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.
Mar 20 2009
prev sibling parent Mike Parker <aldacron gmail.com> writes:
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.
Mar 20 2009