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.

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

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!

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

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.

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

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

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.

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