• downs (18/18) Jul 30 2009 In this post, I present a simple rule of thumb that covers most cases of...
• language_fan (3/5) Jul 30 2009 Isn't D simpler to implement than C++ because the template syntax goes
• downs (2/9) Jul 30 2009 Simpler to parse, mostly.
• Walter Bright (3/5) Jul 30 2009 Since I'm the only person to have implemented both, I think I'm in a
• downs (2/8) Jul 30 2009 Well, I can't really argue with that, but please consider that you imple...
• downs (5/13) Jul 30 2009 Word of explanation follow-up: when I started writing the original post,...
• Walter Bright (8/14) Jul 30 2009 The problem is, I know of no way to make a simple, consistent, small
• Robert Fraser (2/5) Jul 30 2009 It would be the _ultimate_ pimpmobile.
• Walter Bright (4/9) Jul 30 2009 When I implemented C++ back in 1986 or so, the "gold standard" was
• downs (4/4) Jul 30 2009 To clarify for a few criticisms that have come up in IRC: this is meant ...
• Lars T. Kyllingstad (5/10) Jul 31 2009 assert statements are skipped in release mode. We'd need a
• downs (2/18) Jul 31 2009 Or, yanno, an inliner.
• Leandro Lucarella (18/23) Jul 31 2009 I like the idea of moving as much as possible to library code, but for t...
• downs (3/22) Jul 31 2009 Exactly my thoughts.
• Michiel Helvensteijn (29/42) Jul 30 2009 Compile-time proof of assertion/contract correctness would be far more
• downs (9/67) Jul 30 2009 I honestly didn't think of that.
• Robert Fraser (2/7) Jul 30 2009 But "for" is a word, while "foreach" isn't! ;-P
• Sergey Gromov (5/19) Jul 31 2009 This is one weird rule. This is probably because I'm not a native
• downs (2/24) Jul 31 2009 You left out the part where I specifically excluded C keywords, because ...
• Rainer Deyke (11/13) Jul 31 2009 Actually I'd like to see all type names treated as built-in library

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?

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

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.

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!

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

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.

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?

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.

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

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.

"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

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.

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

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.

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

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!

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

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?

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

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