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

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.

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.

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

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?

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.

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!

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

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