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

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
>
>

> 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

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

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

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

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

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>

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

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.