In this post, I present a simple rule of thumb that covers most cases of the common decision: should a feature go in the compiler, or in the standard library?

Note: this only applies to features that aren't in C.

1) If it's a word, put it in the standard library.
2) Otherwise, put it in the compiler.

For example:

assert() -> library.
complex -> library.
void -> C-derived, compiler.
real -> C-derived via long float, compiler.
cfloat -> library.
for -> compiler.
foreach -> library.
T[] -> compiler.
T.dup, T.sort, T.reverse -> library.

I would consider this change more important than all the multithreading improvements made in D2 to date, _maybe_ more important than the const features.

The justification for this change is that words can be trivially looked up in the documentation, thus they aren't deserving of a place in the minimal working set of language features.

As it stands, the claim on the homepage that it's easier to implement a D compiler than a C++ one is highly dubious. This rule, consistently applied, would help bring back some of the simplicity that was lost during the D2.0 feature frenzy.

Your thoughts?

Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:

> As it stands, the claim on the homepage that it's easier to implement a D compiler than a C++ one is highly dubious.

Isn't D simpler to implement than C++ because the template syntax goes like !(foo) instead of <foo>?

downs wrote:
> As it stands, the claim on the homepage that it's easier to implement
> a D compiler than a C++ one is highly dubious.

Since I'm the only person to have implemented both, I think I'm in a good position to judge that yes, it is easier!

Walter Bright wrote:
> downs wrote:
>> As it stands, the claim on the homepage that it's easier to implement a D compiler than a C++ one is highly dubious.
> 
> Since I'm the only person to have implemented both, I think I'm in a good position to judge that yes, it is easier!

Well, I can't really argue with that, but please consider that you implemented the C++ compiler against a "known set of features", at least in part, so to speak, whereas DMD grew with the language. An outsider would face the difficulty of building a reliable C++ compiler, vs. a reliable D compiler, _from scratch_.

language_fan wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:
> 
>> As it stands, the claim on the homepage that it's easier to implement a D compiler than a C++ one is highly dubious.
> 
> Isn't D simpler to implement than C++ because the template syntax goes like !(foo) instead of <foo>?

Simpler to parse, mostly.

To clarify for a few criticisms that have come up in IRC: this is meant as a rule of thumb to fall back on where no other considerations are present.

For instance, const and shared are type constructors, and as such hard to do in the standard library.

To my knowledge, assert() for instance has no such mitigating considerations.

Just wanted to clear that up.

downs wrote:
> Walter Bright wrote:
>> downs wrote:
>>> As it stands, the claim on the homepage that it's easier to implement a D compiler than a C++ one is highly dubious.
>> Since I'm the only person to have implemented both, I think I'm in a good position to judge that yes, it is easier!
> 
> Well, I can't really argue with that, but please consider that you implemented the C++ compiler against a "known set of features", at least in part, so to speak, whereas DMD grew with the language. An outsider would face the difficulty of building a reliable C++ compiler, vs. a reliable D compiler, _from scratch_.

Word of explanation follow-up: when I started writing the original post, I thought the homepage said D strived to be simple to implement; when I checked and found it actually said that D strived to be simpler than C++ I had to change my post.

Walter, of course I didn't intend to criticize your knowledge of your own compiler; the implied accusation makes me feel bad in retrospect :p

It's just that I feel that D could and should be simpler than it is, and I'm worried that no attention will be paid to that problem before the 2.0 release.

That is all, really.

downs wrote:

> 1) If it's a word, put it in the standard library.
> 2) Otherwise, put it in the compiler.

What an interesting theory.

> For example:
> 
> assert() -> library.

Compile-time proof of assertion/contract correctness would be far more problematic.

> complex -> library.
> void -> C-derived, compiler.

I believe void should be a typedef of the empty type-tuple. That would be library.

> real -> C-derived via long float, compiler.
> cfloat -> library.
> for -> compiler.

Might as well put this one in a library, since it's easy to simulate with a while-loop. The only reason D can't is that, as far as I know, it doesn't support trailing delegate literals after a function-call, that fill the role of its last actual parameter.

> foreach -> library.

Perhaps. But that would make static analysis more problematic.

> T[] -> compiler.

I'd rather see dynamic arrays in a library. A template class that overloads the T[] notation. Isn't it true that programmers don't have any control over the allocation strategies and such of the built-in data-structures?

> T.dup, T.sort, T.reverse -> library.

Agreed on that one.

But what about these:

const
immutable
class
struct
typedef
template
ref
shared

Well, you get the point. It turns out to be a bit of a silly rule, doesn't it? Perhaps you meant: "If it's a word, put it in the standard library, unless it belongs in the core language." :-)

-- 
Michiel Helvensteijn

downs wrote:
> Well, I can't really argue with that, but please consider that you
> implemented the C++ compiler against a "known set of features", at
> least in part, so to speak, whereas DMD grew with the language. An
> outsider would face the difficulty of building a reliable C++
> compiler, vs. a reliable D compiler, _from scratch_.


When I implemented C++ back in 1986 or so, the "gold standard" was Cfront, not the spec. DMC++ definitely did grow with the language, and it was "from scratch".

downs wrote:
> Walter, of course I didn't intend to criticize your knowledge of your
> own compiler; the implied accusation makes me feel bad in retrospect
> :p

No reason to feel bad. I'm not insulted :-)

> It's just that I feel that D could and should be simpler than it is,
> and I'm worried that no attention will be paid to that problem before
> the 2.0 release.

The problem is, I know of no way to make a simple, consistent, small language that is also powerful. And these days, programmers demand a powerful language.

Compare your car with a Model T. The T is simple, easily repaired, easily understood. But who wants to drive a T these days compared with driving a modern car?