I'm wondering if it wouldn't be easier - and would facilitate quicker
adoption of the language - if the first implementation of D was a
translator, not a compiler. Many C compilers, for example, do not
compile directly to machine code; the compile to assembly language and
let an assembler create the machine code.
D could be done similarly; you could write a command-line translator (in
ANSI C) that would translate a set of D modules down to a single massive
C source file (or maybe a set of C source files). Then we could
leverage existing C compiler technology to create binaries.
This would allow a single implementation to immediately be ported to all
platforms.
Later, we could work on a dedicated D compiler or a gcc frontend.

Just the effort of creating this translator means that you have the lexical,
syntactical, and semantice analyzers completed; you've completed most of the
work of a full D compiler. Whether you then take the time to translate into
another language or spit out some object code is (IMHO) the same amount of
work (perhaps more to complete the translation). So when you get that far
you might as well finish it the right way...
Would translating into C and/or C++ have a positive or negative effect on
language acceptance? If anything, I'd guess negative (increased build times
to translate from one language to another).
Dave Nebinger
dnebinger riteaid.com

Just the effort of creating this translator means that you have the lexical,
syntactical, and semantice analyzers completed; you've completed most of the
work of a full D compiler. Whether you then take the time to translate into
another language or spit out some object code is (IMHO) the same amount of
work (perhaps more to complete the translation). So when you get that far
you might as well finish it the right way...

True, the hard work of the compiler is already done. However, since the
structure of the language closely mirrors C, I suspect that it would be *much*
easier to spit out C code (especially unreadable, poorly formatted C code) than
it would be to create assembler. Also, the the "code-generator" needs to be
re-implemented (and re-tested) on EVERY platform, rather than just once. I
suspect that the real work of writing a compiler or translator would not be in
writing it, but in testing it to confirm conformance to the spec. That is far
easier, I would guess, with translator as compared to a full compiler.

Would translating into C and/or C++ have a positive or negative effect on
language acceptance? If anything, I'd guess negative (increased build times
to translate from one language to another).

Yes, it would increase build times. But it would reduce time-to-market, meaning
that the process of acceptance can start sooner.
I fully expect that full, native, optimized and optimizing D compilers (try
pronouncing that w/o confusion) will come out later.

Would translating into C and/or C++ have a positive or negative effect on
language acceptance? If anything, I'd guess negative (increased build

times

to translate from one language to another).

I implemented the first native C++ compiler. Before then, C++ was a
translator put out by AT&T. Other C extensions were popular, like
ObjectiveC, and there was no indication that C++ was going to win out over
the others. Others may remember history a little differently <g>, but as I
recall C++ just was not popular as a translator. Compiles were too slow,
debuggers didn't support it, and the difficulties dealing with the vagaries
of the back end C compilers of the day were endlessly frustrating.
The first Zortech C++ flew out the door <g>. All of a sudden, despite it
being a rather primitive C++ compared to today, programmers had a fast,
inexpensive, integrated C++ compiler. Interest in the language zoomed. The
success of Zortech C++ is what inspired other major language vendors to do
C++ compilers of their own, and by then, C++ was established as a major
language here to stay.
So, while I claim no credit for the design of C++, I do claim some role in
the early establishment of C++ as a major language rather than a curiosity.
It's also the basis for my figuring that a native implementation is needed.

So, while I claim no credit for the design of C++, I do claim some role in
the early establishment of C++ as a major language rather than a curiosity.
It's also the basis for my figuring that a native implementation is needed.

Fair enough. Can you, then, give a guesstimate how much more/less work it is
to make a compiler as compared to a translator? Would a translator get out the
door faster, and be a good demonstration/standard setting mechanism, or would
it take nearly as long as a full compiler?
Frankly, after reading that somebody with real compiler experience is actually
looking into D, I'm itching to use this language *soon*. :) It would make
some of my projects SO much easier!

So, while I claim no credit for the design of C++, I do claim some role

in

the early establishment of C++ as a major language rather than a

curiosity.

It's also the basis for my figuring that a native implementation is

needed.

Fair enough. Can you, then, give a guesstimate how much more/less work it

is

to make a compiler as compared to a translator? Would a translator get out

the

door faster, and be a good demonstration/standard setting mechanism, or

would

it take nearly as long as a full compiler?

Given an existing back end, it is easier to connect to that than generate C.
Making a full optimizer/code generator is *far* more work than generating C.
One nice fallout with D is that since it is so easy to lex, parse, etc., it
is going to be a smokin' fast compiler. <g>

Frankly, after reading that somebody with real compiler experience is

actually

looking into D, I'm itching to use this language *soon*. :) It would make
some of my projects SO much easier!

Well, I'm itching to use it too! It's (of course) the language I always
wanted, but nobody else made. In my experiments with it, it helps me get my
own work done much faster.

Would translating into C and/or C++ have a positive or negative effect on
language acceptance? If anything, I'd guess negative (increased build

times

to translate from one language to another).

I implemented the first native C++ compiler. Before then, C++ was a
translator put out by AT&T.

Minor nit:
Not that it hurts any of the other points you make here (in fact,
it supports your points about performance), but IIRC, Stroustrup
goes to some lengths in _Design and Evolution..._ to explain that
Cfront wasn't a 'mere translator'[1], but a full-blown compiler that
used C as the target language instead of assembly or machine
language. Zortech would thus be 'the first C++ compiler to target
machine-native object code', or something awkward like that. :)
-Russell B
[1] All compilers are 'translators', but Cfront doesn't merely
rewrite C++ into C. In particular, all compile-time errors are
supposed to be caught be Cfront, rather than the backend.

I implemented the first native C++ compiler. Before then, C++ was a
translator put out by AT&T.

Minor nit:
Not that it hurts any of the other points you make here (in fact,
it supports your points about performance), but IIRC, Stroustrup
goes to some lengths in _Design and Evolution..._ to explain that
Cfront wasn't a 'mere translator'[1], but a full-blown compiler that
used C as the target language instead of assembly or machine
language. Zortech would thus be 'the first C++ compiler to target
machine-native object code', or something awkward like that. :)

Bjarne's legitimate complaint in the 80's was that people dismissed cfront
as just a "preprocessor". It was not a preprocessor (in the sense of a text
preprocessor), but a compiler. I don't remember anyone at the time dissing
it as a "mere" translator.
I agree with Bjarne that successful translators must be real compilers - but
they are not *native* compilers. Translators required the addition of a full
blown C compiler. Bjarne's strategy of making cfront a translator made C++
quickly available on a wide variety of platforms. AT&T's generous policy of
letting others make implementations was crucial. I remember writing a letter
to AT&T's lawyers asking them if I could call my product "C++", since AT&T
owned the name. (They said yes!) I wish I could find that letter, it would
be a nice bit of memorabilia. I don't think anyone else ever asked!

D could be done similarly; you could write a command-line translator (in
ANSI C) that would translate a set of D modules down to a single massive
C source file (or maybe a set of C source files). Then we could
leverage existing C compiler technology to create binaries.

Addendums:
* Since C types have varying sizes, you might have to use typedefs or some
such to get ints of the right sizes. That means that the translator won't
technically be 100% portable, but the logic could be... (Similar issues
with translating aligned D structures into C)
* Going to C means you'll likely lose some of the optimizations that D
allows.

It originally started out that way. The trouble started in when some D
concepts just were not easilly expressed in C. The try-catch-finally is a
case in point. -Walter
Russ Lewis wrote in message <3B7D350E.FB941F8A deming-os.org>...

I'm wondering if it wouldn't be easier - and would facilitate quicker
adoption of the language - if the first implementation of D was a
translator, not a compiler. Many C compilers, for example, do not
compile directly to machine code; the compile to assembly language and
let an assembler create the machine code.
D could be done similarly; you could write a command-line translator (in
ANSI C) that would translate a set of D modules down to a single massive
C source file (or maybe a set of C source files). Then we could
leverage existing C compiler technology to create binaries.
This would allow a single implementation to immediately be ported to all
platforms.
Later, we could work on a dedicated D compiler or a gcc frontend.