• Russ Lewis (12/12) Aug 17 2001 I'm wondering if it wouldn't be easier - and would facilitate quicker
• Dave Nebinger (11/11) Aug 17 2001 Just the effort of creating this translator means that you have the lexi...
• Russ Lewis (13/22) Aug 17 2001 True, the hard work of the compiler is already done. However, since the
• Walter (18/21) Aug 17 2001 I implemented the first native C++ compiler. Before then, C++ was a
• Russ Lewis (8/11) Aug 17 2001 Fair enough. Can you, then, give a guesstimate how much more/less work ...
• Walter (15/26) Aug 17 2001 curiosity.
• Kent Sandvik (7/11) Aug 17 2001 C.
• Walter (2/14) Aug 17 2001 Because it's bootstrapped, it's in C++.
• Russell Bornschlegel (13/22) Aug 17 2001 Minor nit:
• Walter (13/24) Aug 17 2001 Bjarne's legitimate complaint in the 80's was that people dismissed cfro...
• Russ Lewis (8/12) Aug 17 2001 Addendums:
• Walter (4/16) Aug 17 2001 It originally started out that way. The trouble started in when some D
• Russ Lewis (3/6) Aug 17 2001 I'm not a compiler writer, so I don't understand. It would seem (from t...
• Walter (4/10) Aug 17 2001 Implementing exceptions needs back end support. This just isn't there in...
• Russ Lewis (4/16) Aug 17 2001 *&@#$@#$%

Russ Lewis <russ deming-os.org> writes:

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.

"Dave Nebinger" <dnebinger riteaid.com> writes:

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

Russ Lewis <russ deming-os.org> writes:

Dave Nebinger wrote:

 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.

"Walter" <walter digitalmars.com> writes:

Dave Nebinger wrote in message <9lji2j$1n07$1 digitaldaemon.com>...
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.

Russ Lewis <russ deming-os.org> writes:

Walter wrote:

 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!

"Walter" <walter digitalmars.com> writes:

Russ Lewis wrote in message <3B7D817E.B453B499 deming-os.org>...
Walter wrote:
 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.

"Kent Sandvik" <sandvik excitehome.net> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9lk2ce$2bo3$1 digitaldaemon.com...
 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>

Would the front end be initially written in D? Always hard to boot strap,
but it would speed up things concerning implementation issues. --Kent

"Walter" <walter digitalmars.com> writes:

Kent Sandvik wrote in message <9lk3ga$2chc$1 digitaldaemon.com>...
"Walter" <walter digitalmars.com> wrote in message
news:9lk2ce$2bo3$1 digitaldaemon.com...
 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>

Would the front end be initially written in D? Always hard to boot strap,
but it would speed up things concerning implementation issues. --Kent


Because it's bootstrapped, it's in C++.

Russell Bornschlegel <kaleja estarcion.com> writes:

Walter wrote:
 
 Dave Nebinger wrote in message <9lji2j$1n07$1 digitaldaemon.com>...
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.

"Walter" <walter digitalmars.com> writes:

Russell Bornschlegel wrote in message <3B7D9302.AF5F8B9F estarcion.com>...
Walter wrote:
 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!

Russ Lewis <russ deming-os.org> writes:

Russ Lewis wrote:

 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.

"Walter" <walter digitalmars.com> writes:

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.

Russ Lewis <russ deming-os.org> writes:

Walter wrote:

 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

I'm not a compiler writer, so I don't understand.  It would seem (from the
outside) like a simple goto would work...why does this fail?

"Walter" <walter digitalmars.com> writes:

Russ Lewis wrote in message <3B7D7ED9.56FA2E1C deming-os.org>...
Walter wrote:

 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

I'm not a compiler writer, so I don't understand.  It would seem (from the
outside) like a simple goto would work...why does this fail?


Implementing exceptions needs back end support. This just isn't there in C.
There are wretched ways to do it, but I really don't want to implement a
wretched compiler <g>.

Russ Lewis <russ deming-os.org> writes:

Walter wrote:

 Russ Lewis wrote in message <3B7D7ED9.56FA2E1C deming-os.org>...
Walter wrote:

 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

I'm not a compiler writer, so I don't understand.  It would seem (from the
outside) like a simple goto would work...why does this fail?

 Implementing exceptions needs back end support. This just isn't there in C.
 There are wretched ways to do it, but I really don't want to implement a
 wretched compiler <g>.



Fair enough.  C++ might be able to do it (somewhat), but C++ implementation, in
my limited experience, is not very consistent :(