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



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




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


Write

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


effort

 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.


Write

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


effort

 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.




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.



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.




 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.


 
 
 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