www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A simple rule

reply downs <default_357-line yahoo.de> writes:
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?
Jul 30 2009
next sibling parent reply language_fan <foo bar.com.invalid> writes:
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>?
Jul 30 2009
parent downs <default_357-line yahoo.de> writes:
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.
Jul 30 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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!
Jul 30 2009
parent reply downs <default_357-line yahoo.de> writes:
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_.
Jul 30 2009
next sibling parent reply downs <default_357-line yahoo.de> writes:
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.
Jul 30 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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?
Jul 30 2009
parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 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?
It would be the _ultimate_ pimpmobile.
Jul 30 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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".
Jul 30 2009
prev sibling next sibling parent reply downs <default_357-line yahoo.de> writes:
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.
Jul 30 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
downs wrote:
 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.
assert statements are skipped in release mode. We'd need a version(norelease) or something if assert() was to be moved to the standard library. -Lars
Jul 31 2009
parent downs <default_357-line yahoo.de> writes:
Lars T. Kyllingstad wrote:
 downs wrote:
 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.
assert statements are skipped in release mode. We'd need a version(norelease) or something if assert() was to be moved to the standard library. -Lars
Or, yanno, an inliner.
Jul 31 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
downs, el 30 de julio a las 22:31 me escribiste:
 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.
I like the idea of moving as much as possible to library code, but for the sake of simplicity, I think most of the stuff moved should be "built-in", like Object, ClassInfo, etc. You shouldn't import anything to use assert() if you want to promote it's use, like I said with tuples (I think even references, dynamic arrays and associative arrays should live in the library, even when they have specialized syntax). This could make implementing a new compiler way simpler if you have an standard library/runtime available. And you have the extra advantage of being able to change the implementation of core constructs without touching the compiler. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Sometimes I think the sure sign that life exists elsewhere in the universe Is that that none of them tried to contact us
Jul 31 2009
parent downs <default_357-line yahoo.de> writes:
Leandro Lucarella wrote:
 downs, el 30 de julio a las 22:31 me escribiste:
 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.
I like the idea of moving as much as possible to library code, but for the sake of simplicity, I think most of the stuff moved should be "built-in", like Object, ClassInfo, etc. You shouldn't import anything to use assert() if you want to promote it's use, like I said with tuples (I think even references, dynamic arrays and associative arrays should live in the library, even when they have specialized syntax).
Oh I fully agree; stuff like assert belongs in a public import from object.d.
 This could make implementing a new compiler way simpler if you have an
 standard library/runtime available. And you have the extra advantage of
 being able to change the implementation of core constructs without
 touching the compiler.
 
Exactly my thoughts.
Jul 31 2009
prev sibling next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
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
Jul 30 2009
parent downs <default_357-line yahoo.de> writes:
Michiel Helvensteijn wrote:
 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.
Well to be fair, we don't do that anyway.
 complex -> library.
 void -> C-derived, compiler.
I believe void should be a typedef of the empty type-tuple. That would be library.
I honestly didn't think of that.
 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.
I mainly inserted the "C-derived stuff in the language" rule so we'd have a set of primitives. The problem with for is that it has a fixed syntax that would require more than a few changes to D .. trailing delegate alone wouldn't cut it, you'd need a way to specify a fully extensible syntax and we'll probably never have that.
 foreach -> library.
Perhaps. But that would make static analysis more problematic.
Inlining ~
 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?
As I understand, D will probably never have the extensible syntax necessary to support that. No, strictly speaking it's not _quite_ true. Arrays can be wrapped over existing pointers; these pointers can be acquired using any strategy you want. Of course, appending and such will move it back into GC space :)
 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." :-)
Actually, I qualified that in another post .. it's meant more as a fallback when there aren't compelling reasons to put it in the compiler. Thanks for the response!
Jul 30 2009
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
downs wrote:
 1) If it's a word, put it in the standard library.
 2) Otherwise, put it in the compiler.
 
 for -> compiler.
 foreach -> library.
But "for" is a word, while "foreach" isn't! ;-P
Jul 30 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 30 Jul 2009 21:57:33 +0200, downs wrote:

 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.
This is one weird rule. This is probably because I'm not a native English speaker, but I fail to see why 'complex' and 'foreach' are words but 'for' is not. You probably need to clarify what a 'word' is. Should all key /words/ go into the library?
Jul 31 2009
parent reply downs <default_357-line yahoo.de> writes:
Sergey Gromov wrote:
 Thu, 30 Jul 2009 21:57:33 +0200, downs wrote:
 
 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.
This is one weird rule. This is probably because I'm not a native English speaker, but I fail to see why 'complex' and 'foreach' are words but 'for' is not. You probably need to clarify what a 'word' is. Should all key /words/ go into the library?
You left out the part where I specifically excluded C keywords, because it's good to have some base set to fall back on :)
Jul 31 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
downs wrote:
 You left out the part where I specifically excluded C keywords,
 because it's good to have some base set to fall back on :)
Actually I'd like to see all type names treated as built-in library types instead of treating them as part of the core language. Advantages: - Simpler parser, simpler language specification. - If you really need to, you can interface with external libraries that use e.g. 'int' as an identifier. Major disadvantage: - You can use 'int' as an identifier. -- Rainer Deyke - rainerd eldwood.com
Jul 31 2009