www.digitalmars.com         C & C++   DMDScript  

D - D and alternatives.

reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
I have checked out the alternatives to D which have been introduced
here. Comparisions so far have concentrated on comparing the languages,
but there are also differences in the availablility.  Both LX and Dtone
are supplied for use in a  UNIX context. Dtone suggests Windows users
should use cygwin.  LX is supplied with makefiles for Linux.

Walter hasn't discussed this explicitly, but said he was going to use
the same backend as DM, so that the compiler would be PC based.

This means that the choice of the best language has to be influenced by
the target environment, which may be constrained.

I have learned so much from this discussion.

John Fletcher
Aug 17 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
You're right in inferring that the first D compiler will be for win32 only.
When it's all working, I hope to convince people to integrate it with GCC.
Until then, it would be a bad idea to try a port with a constantly evolving
code base <g>.

Alternatively, I might look at generating C output.

John Fletcher wrote in message <3B7D3C2E.D73DE133 aston.ac.uk>...
I have checked out the alternatives to D which have been introduced
here. Comparisions so far have concentrated on comparing the languages,
but there are also differences in the availablility.  Both LX and Dtone
are supplied for use in a  UNIX context. Dtone suggests Windows users
should use cygwin.  LX is supplied with makefiles for Linux.

Walter hasn't discussed this explicitly, but said he was going to use
the same backend as DM, so that the compiler would be PC based.

This means that the choice of the best language has to be influenced by
the target environment, which may be constrained.

I have learned so much from this discussion.

John Fletcher

Aug 17 2001
next sibling parent reply Tom Waddington <tom waddie.org.uk> writes:
Hello Walter,

First off, I'd just like to say that I found the D spec both
intriguing and encouraging.  I've never been really happy with C++,
so the prospect of a real alternative is extremely exciting.

 You're right in inferring that the first D compiler will be for
 win32 only. When it's all working, I hope to convince people to
 integrate it with GCC.

Does `all working' mean the alpha compiler, or a real Windows D Compiler v1.0? I suspect that if it looks like being Windows only for the foreseeable future, a lot of people running other operating systems will rapidly lose interest. How much that concerns you is another matter, but I think the Linux world could be the major market for Yet Another Language, at least initially, and especially with Microsoft putting so much effort into promoting C# on Windows.
 Until then, it would be a bad idea to try a port with a constantly
 evolving code base <g>.

I'm not so sure about that. I think a team of porters from the start could be very helpful in ensuring that the language and library are easily portable. Of course, they'd have to be patient and understanding to deal with the major revisions that are inevitable in the early stages of a project like this, but the gains in feedback and widespread interest would probably be worth it.
 Alternatively, I might look at generating C output.

Better than nothing. ;) Be seeing you, -- Tom Waddington
Aug 17 2001
parent "Brent Schartung" <bschartung home.com> writes:
Why not take the Adaptive Component Environment's (ACE) approach-- you write
a little wrapper library for things that get hairy in the cross-platform
part; i.e., you have a socket class (or heirarchy even) that has -eek-
preprocessor statements for all the OSes' socket libraries.  And another for
threads.  And possibly a set of UINT16, UINT32, etc.  Ooh, not to mention
the filesystem stuff--BTW, does anyone know a better way of doing directory
listings on Win32 than a popen( ) to 'dir /b'?  (I think there is one in the
Windows API somewhere...)

Anyways, if you do this part carefully, it will be possible to keep
cross-platform maintainance to a minimum.  Then again, I'm not terribly
experienced in this, so I could be very wrong!  ( :

 - Brent


 Until then, it would be a bad idea to try a port with a constantly
 evolving code base <g>.

I'm not so sure about that. I think a team of porters from the start could be very helpful in ensuring that the language and library are easily portable. Of course, they'd have to be patient and understanding to deal with the major revisions that are inevitable in the early stages of a project like this, but the gains in feedback and widespread interest would probably be worth it.

Aug 18 2001
prev sibling next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:
 
 You're right in inferring that the first D compiler will be for win32 only.
 When it's all working, I hope to convince people to integrate it with GCC.
 Until then, it would be a bad idea to try a port with a constantly evolving
 code base <g>.

Just write the code portably to begin with. :) -Russell B
Aug 17 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Walter wrote:

 When it's all working, I hope to convince people to integrate it
 with GCC. 

This is just an early advice, not a threat or something. I think it's better to inform people early than to surpise them late. I don't know how exactly you're planning but you seem to be facing legal problems. Best would be to ask the FSF for details, they know how things really are I can only guess from what I know. When integrating a frontend into GCC, it must be aviable under the GPL (like the objective-c author long took a time to be "convinced" that he's supposed to make his changes aviable) However the GPL is problematic if you want to link the compiler at the same time with properitary libraries/code. As long you're the only author of the compiler this of course no problem, you can do with your stuff always what you want, no license whatsoever can interfere there. Okay from what I read you'll allow the source of the frontend to be open and don't have a problem with it to be covered by the GPL. However the problem arises as soon you accept patches, you'll be no longer the sole author of this product, no problem in the GPL area. But you'll face problems if you then want to link it with properitary libraries. One common solution to this properitary library problem is to make additional exceptions to the GPL to allow linking to certain libraries (like in example suns java runtime). However the problem again with GPL with exceptions it's no longer -the- GPL but a GPL with additional stuff. So you cannot link it legally by default with GPL stuff like the gcc backend. I think it's better in this area to consult the FSF for clearness early, than sorryness late. An additional possible thing I see is what parser generator are you using? Is it aviable broadly? I just want to suggest to be heedful in this area, I don't want to people to repulse from the GPL it's something good in my eyes, but information and care is important. The last thing we want to see is you beeing forced in example in two years to have to release the source from something you would not want to. Again I might be wrong, better consult the people who know their stuff :o) - Axel
Aug 17 2001
parent reply "Walter" <walter digitalmars.com> writes:
Good points. One thought might be to make the front end "open source", not
gpl. Then, encourage people to make a seperate GPL version, using the open
source version as a sort of reference manual. I get a lot of flak for making
implementation ease a priority <g>, but this is one reason why.

-Walter

Axel Kittenberger wrote in message <9ljrqq$26qs$1 digitaldaemon.com>...
Walter wrote:

 When it's all working, I hope to convince people to integrate it
 with GCC.

This is just an early advice, not a threat or something. I think it's better to inform people early than to surpise them late. I don't know how exactly you're planning but you seem to be facing legal problems. Best would be to ask the FSF for details, they know how things really are I can only guess from what I know. When integrating a frontend into GCC, it must be aviable under the GPL (like the objective-c author long took a time to be "convinced" that he's supposed to make his changes aviable) However the GPL is problematic if you want to link the compiler at the same time with properitary libraries/code. As long you're the only author of the compiler this of course no problem, you can do with your stuff always what you want, no license whatsoever can interfere there. Okay from what I read you'll allow the source of the frontend to be open and don't have a problem with it to be covered by the GPL. However the problem arises as soon you accept patches, you'll be no longer the sole author of this product, no problem in the GPL area. But you'll face problems if you then want to link it with properitary libraries. One common solution to this properitary library problem is to make additional exceptions to the GPL to allow linking to certain libraries (like in example suns java runtime). However the problem again with GPL with exceptions it's no longer -the- GPL but a GPL with additional stuff. So you cannot link it legally by default with GPL stuff like the gcc backend. I think it's better in this area to consult the FSF for clearness early, than sorryness late. An additional possible thing I see is what parser generator are you using? Is it aviable broadly? I just want to suggest to be heedful in this area, I don't want to people to repulse from the GPL it's something good in my eyes, but information and care is important. The last thing we want to see is you beeing forced in example in two years to have to release the source from something you would not want to. Again I might be wrong, better consult the people who know their stuff :o) - Axel
Aug 17 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
BSD it instead of GPL!
I personally like the BSD license a LOT better.

Jan



Walter wrote:

 Good points. One thought might be to make the front end "open source", not
 gpl. Then, encourage people to make a seperate GPL version, using the open
 source version as a sort of reference manual. I get a lot of flak for making
 implementation ease a priority <g>, but this is one reason why.

 -Walter

 Axel Kittenberger wrote in message <9ljrqq$26qs$1 digitaldaemon.com>...
 Walter wrote:

 When it's all working, I hope to convince people to integrate it
 with GCC.

This is just an early advice, not a threat or something. I think it's better to inform people early than to surpise them late. I don't know how exactly you're planning but you seem to be facing legal problems. Best would be to ask the FSF for details, they know how things really are I can only guess from what I know. When integrating a frontend into GCC, it must be aviable under the GPL (like the objective-c author long took a time to be "convinced" that he's supposed to make his changes aviable) However the GPL is problematic if you want to link the compiler at the same time with properitary libraries/code. As long you're the only author of the compiler this of course no problem, you can do with your stuff always what you want, no license whatsoever can interfere there. Okay from what I read you'll allow the source of the frontend to be open and don't have a problem with it to be covered by the GPL. However the problem arises as soon you accept patches, you'll be no longer the sole author of this product, no problem in the GPL area. But you'll face problems if you then want to link it with properitary libraries. One common solution to this properitary library problem is to make additional exceptions to the GPL to allow linking to certain libraries (like in example suns java runtime). However the problem again with GPL with exceptions it's no longer -the- GPL but a GPL with additional stuff. So you cannot link it legally by default with GPL stuff like the gcc backend. I think it's better in this area to consult the FSF for clearness early, than sorryness late. An additional possible thing I see is what parser generator are you using? Is it aviable broadly? I just want to suggest to be heedful in this area, I don't want to people to repulse from the GPL it's something good in my eyes, but information and care is important. The last thing we want to see is you beeing forced in example in two years to have to release the source from something you would not want to. Again I might be wrong, better consult the people who know their stuff :o) - Axel

-- Jan Knepper Smartsoft, LLC 88 Petersburg Road Petersburg, NJ 08270 U.S.A. http://www.smartsoft.cc/ Phone : 609-628-4260 FAX : 609-628-1267 In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <forsythe alum.mit.edu>
Aug 17 2001
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 Good points. One thought might be to make the front end "open source", not
 gpl. Then, encourage people to make a seperate GPL version, using the open
 source version as a sort of reference manual. I get a lot of flak for making
 implementation ease a priority <g>, but this is one reason why.
 
 -Walter

Here's another alternative: If you release a GPL version, there's nothing that prevents you from also releasing a version with your license on it. It only prevents other people from doing that. You can use whatever other licenses you like. And then there's the MPL (Mozilla) and the QPL (TrollTech). True, TrollTech had some problems getting their license accepted, but it was eventually. Still, gcc may require GPL. And if so, then it's the dual-license choice that is feasible for the plans that you mention. If you choose to do this, then you would need to get any contributors to assign their copyrights to you, to enable the licensing of compatible versions both as GPL and as whatever license you choose.
Aug 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
I ran across another solution.

Have D write an intermediate file out in some simple generic language. Write
a front end for gcc that compiles the generic language. There's some effort
this way already (the C-- project).


Charles Hixson wrote in message <3B817012.3010606 earthlink.net>...
Walter wrote:
 Good points. One thought might be to make the front end "open source",


 gpl. Then, encourage people to make a seperate GPL version, using the


 source version as a sort of reference manual. I get a lot of flak for


 implementation ease a priority <g>, but this is one reason why.

 -Walter

Here's another alternative: If you release a GPL version, there's nothing that prevents you from also releasing a version with your license on it. It only prevents other people from doing that. You can use whatever other licenses you like. And then there's the MPL (Mozilla) and the QPL (TrollTech). True, TrollTech had some problems getting their license accepted, but it was eventually. Still, gcc may require GPL. And if so, then it's the dual-license choice that is feasible for the plans that you mention. If you choose to do this, then you would need to get any contributors to assign their copyrights to you, to enable the licensing of compatible versions both as GPL and as whatever license you choose.

Aug 20 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
 (the C-- project).

Wooohhaaaaa!!!! Isn't that M$ Visual C--???
Aug 20 2001
prev sibling next sibling parent reply "Angus Graham" <agraham_d agraham.ca> writes:
"Walter" <walter digitalmars.com> wrote:

 I ran across another solution.

 Have D write an intermediate file out in some simple generic language.

 a front end for gcc that compiles the generic language. There's some

 this way already (the C-- project).

Doesn't this make source level debugging difficult (or impossible)? I've had an integrated debugger for as long as I've been programming. Not having one is a definite dealbreaker for me. I don't know how those command line people do it, but I know it's not for me. Angus Graham
Aug 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
Not impossible. You could add the debug info to the generic
language. -Walter

Angus Graham wrote in message <9lsm4a$1j7m$1 digitaldaemon.com>...
"Walter" <walter digitalmars.com> wrote:

 I ran across another solution.

 Have D write an intermediate file out in some simple generic language.

 a front end for gcc that compiles the generic language. There's some

 this way already (the C-- project).

Doesn't this make source level debugging difficult (or impossible)? I've had an integrated debugger for as long as I've been programming. Not having one is a definite dealbreaker for me. I don't know how those command line people do it, but I know it's not for me. Angus Graham

Aug 21 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
Walter wrote:

 Not impossible. You could add the debug info to the generic
 language. -Walter

Not even impossible if the intermediate is C. I just say #file and #line :o) However investigating variables in the debugger will not work, if there is some additional name mangling applied on them :(
Aug 21 2001
next sibling parent Christophe de Dinechin <descubes earthlink.net> writes:
Which brings another interesting point. The preprocessor was the reason why C
had #file and #line. Any chance to have that in D (if someone wants, say, a
yacc to D or something to D converter) ?

Christophe

Axel Kittenberger wrote:

 Walter wrote:

 Not impossible. You could add the debug info to the generic
 language. -Walter

Not even impossible if the intermediate is C. I just say #file and #line :o) However investigating variables in the debugger will not work, if there is some additional name mangling applied on them :(

Aug 22 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
C has problems as an intermediate language. For example, how do I do
exception handling? -Walter

Axel Kittenberger wrote in message <9lu3mu$2e3u$1 digitaldaemon.com>...
Walter wrote:

 Not impossible. You could add the debug info to the generic
 language. -Walter

Not even impossible if the intermediate is C. I just say #file and #line :o) However investigating variables in the debugger will not work, if there is some additional name mangling applied on them :(
Aug 24 2001
parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
"Walter" <walter digitalmars.com> writes:

 C has problems as an intermediate language. For example, how do I do
 exception handling? -Walter

Using longjmp()? There is at least one Ada compiler which uses C as an intermediate language, so this problem can certainly be solved. -- Florian Weimer Florian.Weimer RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Aug 25 2001
parent "Walter" <walter digitalmars.com> writes:
longjmp()? I hadn't thought of that. Not sure how to make that work.

Florian Weimer wrote in message ...
"Walter" <walter digitalmars.com> writes:

 C has problems as an intermediate language. For example, how do I do
 exception handling? -Walter

Using longjmp()? There is at least one Ada compiler which uses C as an intermediate language, so this problem can certainly be solved. -- Florian Weimer Florian.Weimer RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898

Aug 31 2001
prev sibling next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 Have D write an intermediate file out in some simple generic language.
 Write a front end for gcc that compiles the generic language. There's some
 effort this way already (the C-- project).

Now for simplicity let's call that that intermediate format, "C" :o))) Well I know that many other systems like word processor have a common sharing format (ie. .rtf), CAD systems have something similar (.dxf) etc. But to my knowledge there is no generic (as all other generics, ascii based) format for object files/project tree's. Having such would simplify the coders world in odd situation (like this), however making a good format (and integrating it in example in gcc to be read- and writeable) is a nice project for itself. - Axel
Aug 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
Back when the compiler was multi-pass, that's just what it did.


Axel Kittenberger wrote in message <9lsq2d$1lol$1 digitaldaemon.com>...
But to my knowledge there is no generic (as all other generics, ascii
based) format for object files/project tree's. Having such would simplify
the coders world in odd situation (like this), however making a good format
(and integrating it in example in gcc to be read- and writeable) is a nice
project for itself.

- Axel
Aug 21 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 Back when the compiler was multi-pass, that's just what it did.

Huh? I'm confused, gcc? Gcc has an intermediate language (RTL) however it's never written to disk, and according to the docentation it's not even really possibly. I think a major step forward in computing would be not to let the compilers generate native object code, but some intermediate register language. There linker could be allowed to do far improved optimizations, as it could in example scrap unused functions of the image, or is allowed to realize other cross-file depencies. However as I realize such a thing is beyond this particular project :o) It would in majority go about a new gcc backend/target, and a complety new linker with integrated post-compiler/final-optimizer that creates final imagines of this intermediate format. Might be possible that such efforts exists already, however at the GNU I didn't yet hear about it. However from what I understood this one of the key features microsofts tries to archieve with their.net efforts. I just hope the OpenSource world doesn't oversleep this tech. . Axel
Aug 21 2001
next sibling parent Christophe de Dinechin <descubes earthlink.net> writes:
Axel Kittenberger wrote:

 I think a major step forward in computing would be not to let the compilers
 generate native object code, but some intermediate register language.
 There linker could be allowed to do far improved optimizations, as it could
 in example scrap unused functions of the image, or is allowed to realize
 other cross-file depencies.

That's one of the very purposes of the Mozart environment that underlies LX (http://mozart-dev.sf.net) Take a look at the Java-extending plugins. Christophe
Aug 22 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
Back in the early 80's <cough><cough>, the compiler and its data had to fit
in 256Kb. That meant the compiler was split into 3 passes: a parser,
optimizer, and code generator. They communicated with a simple text file.


Axel Kittenberger wrote in message <9lu45m$2eg5$1 digitaldaemon.com>...
 Back when the compiler was multi-pass, that's just what it did.

Huh? I'm confused, gcc? Gcc has an intermediate language (RTL) however it's never written to disk, and according to the docentation it's not even really possibly. I think a major step forward in computing would be not to let the compilers generate native object code, but some intermediate register language. There linker could be allowed to do far improved optimizations, as it could in example scrap unused functions of the image, or is allowed to realize other cross-file depencies. However as I realize such a thing is beyond this particular project :o) It would in majority go about a new gcc backend/target, and a complety new linker with integrated post-compiler/final-optimizer that creates final imagines of this intermediate format. Might be possible that such efforts exists already, however at the GNU I didn't yet hear about it. However from what I understood this one of the key features microsofts tries to archieve with their.net efforts. I just hope the OpenSource world doesn't oversleep this tech. . Axel
Aug 23 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:
 
 I ran across another solution.
 
 Have D write an intermediate file out in some simple generic language. Write
 a front end for gcc that compiles the generic language. There's some effort
 this way already (the C-- project).

Woh. Weren't we poking at early C++ implementations for doing this? I really doubt that the gcc folks would include a meta-language front into the standard gcc just so you could by-pass GPL, and D will never catch on if folks actually have to build a special gcc. I also think this might insult a few people. It is you're choice, but mind the politics. Dan
Aug 24 2001
parent reply "Walter" <walter digitalmars.com> writes:
Dan Hursh wrote in message <3B872C84.10358024 infonet.isl.net>...
Walter wrote:
 I ran across another solution.
 Have D write an intermediate file out in some simple generic language.


 a front end for gcc that compiles the generic language. There's some


 this way already (the C-- project).

really doubt that the gcc folks would include a meta-language front into the standard gcc just so you could by-pass GPL, and D will never catch on if folks actually have to build a special gcc. I also think this might insult a few people. It is you're choice, but mind the politics.

There actually is a gnu project to do just that, called the C-- project. I'm no stranger to insulting people anyway <g>, just my manifesto listing what's wrong with C++ has offended many.
Aug 25 2001
parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 Dan Hursh wrote in message <3B872C84.10358024 infonet.isl.net>...
 
Walter wrote:

I ran across another solution.
Have D write an intermediate file out in some simple generic language.


a front end for gcc that compiles the generic language. There's some


this way already (the C-- project).

really doubt that the gcc folks would include a meta-language front into the standard gcc just so you could by-pass GPL, and D will never catch on if folks actually have to build a special gcc. I also think this might insult a few people. It is you're choice, but mind the politics.

There actually is a gnu project to do just that, called the C-- project. I'm no stranger to insulting people anyway <g>, just my manifesto listing what's wrong with C++ has offended many.

I rather like that solution. Especially if machine dependencies can be kept localized.
Aug 27 2001
prev sibling next sibling parent Axel Kittenberger <axel dtone.org> writes:
 I have checked out the alternatives to D which have been introduced
 here. Comparisions so far have concentrated on comparing the languages,
 but there are also differences in the availablility.  Both LX and Dtone
 are supplied for use in a  UNIX context. Dtone suggests Windows users
 should use cygwin.  LX is supplied with makefiles for Linux.

Maintaining one build system (the bash shell) is easier then taking care of two at the same time, with the decision to use a *nix shell, it's aviable to huge user base, windows users included. However one task the compiler does is to read directory listings, this rather simplistic task has unfortunally after all this years of computing still a platform dependent interface. Well at some earlier stage the Dtone compiler ran also on windows, and the windows source code is still included altough commented out. In the middle of develment supporting multiple platforms is difficult, especially windows, since it is so different to all the other things. Altough there is no technical reason behind not to run windows. If somebody raises his hand to volunteers to maintain windows compability I would of course be glad and invite him to do so, if not I for me will concententrate on my development platform. - Axel
Aug 17 2001
prev sibling parent reply Christophe de Dinechin <descubes earthlink.net> writes:
Ouch, please don't call LX an "alternative" to D. I would not spend so
much time in this forum if I saw things as black and white :-) Choice is
good. And just to clarify, LX has been ported to BeOS, and a Windows port
is under way (although I did not hear back... Hmmm)


Christophe

John Fletcher wrote:

 I have checked out the alternatives to D which have been introduced
 here. Comparisions so far have concentrated on comparing the languages,
 but there are also differences in the availablility.  Both LX and Dtone
 are supplied for use in a  UNIX context. Dtone suggests Windows users
 should use cygwin.  LX is supplied with makefiles for Linux.

 Walter hasn't discussed this explicitly, but said he was going to use
 the same backend as DM, so that the compiler would be PC based.

 This means that the choice of the best language has to be influenced by
 the target environment, which may be constrained.

 I have learned so much from this discussion.

 John Fletcher

Aug 18 2001
parent John Fletcher <J.P.Fletcher aston.ac.uk> writes:
Christophe de Dinechin wrote:

 Ouch, please don't call LX an "alternative" to D. I would not spend so
 much time in this forum if I saw things as black and white :-) Choice is
 good. And just to clarify, LX has been ported to BeOS, and a Windows port
 is under way (although I did not hear back... Hmmm)

 Christophe

Sorry for my misunderstanding. John
Aug 20 2001