http://web.archive.org/web/20010830214723/www.digitalmars.com/d/

It's the D spec from August 2001.  It's fun to see what D _used_ to be, and the, cough, lovable monster it's become today ;)

Jarrett Billingsley wrote:
> http://web.archive.org/web/20010830214723/www.digitalmars.com/d/
> 
> It's the D spec from August 2001.  It's fun to see what D _used_ to be, and the, cough, lovable monster it's become today ;)

Some interesting differences:

* real used to be extended.
* alias used to be typealias.
* Good old bit :D
* Phobos used to be called "D Class Library" and only had 11 classes in
it: Math, File, String, Regexp, GC, Thread, Process, Date, Zip, System
and Random.
* There were TWO character types: ascii and unicode; unicode changed
size by platform (16-bits under Windows, 32-bit under linux).  And
people think char[], wchar[], dchar[] is messy!
* version didn't take an identifier; it actually evaluated an
expression.  One example given was: version(system.os == OS.WindowsNT)
* No foreach!
* Classes didn't have protection attributes on super classes.
Considering this has never done anything AFAIK, I wonder why it was ever
added...
* There were no packages, meaning all your modules were shoved into a
single namespace!
* No templates!

From the FAQ:

When can I get a D compiler?
I'm hard at work on one. I hope in a couple months. I had not
anticipated being slashdotted.

A time when no D compilers existed?  Such a dark, barbaric time...

What about templates?
Templates were not in the original plans for D. C++ was wildly
successful even before templates were added, and Java is wildly
successful without templates. The feedback I've been getting, however,
is that D will not be successful without some form of templates, so in
they go.

Whoever it was that convinced Walter to add templates: THANK YOU!

Why emphasize implementation ease?
Isn't ease of use for the user of the language more important? Yes, it is...

HAHAHAHA *snort*

Sorry, but you can't seriously claim D is still easy to implement whilst .stringof still exists in its current form.  :P

On Thu, Jul 23, 2009 at 10:23 PM, Daniel Keep<daniel.keep.lists@gmail.com> wrote:
> Sorry, but you can't seriously claim D is still easy to implement whilst .stringof still exists in its current form.  :P

Oh, .stringof is nothing compared to the complexity added by string mixins ;)

Or some of the scarier parsing issues.  (Type).Identifier and the (int
x) { return x + 5; } delegates are two things that come to mind..

Jarrett Billingsley wrote:
> On Thu, Jul 23, 2009 at 10:23 PM, Daniel Keep<daniel.keep.lists@gmail.com> wrote:
>> Sorry, but you can't seriously claim D is still easy to implement whilst .stringof still exists in its current form.  :P
> 
> Oh, .stringof is nothing compared to the complexity added by string mixins ;)
> 
> Or some of the scarier parsing issues.  (Type).Identifier and the (int
> x) { return x + 5; } delegates are two things that come to mind..

What's up with the last two? I haven't quite gotten to them in semantic yet, but I didn't notice any problems in parsing them

On Tue, Jul 28, 2009 at 2:43 AM, Ellery Newcomer<ellery-newcomer@utulsa.edu> wrote:
> Jarrett Billingsley wrote:
>> On Thu, Jul 23, 2009 at 10:23 PM, Daniel Keep<daniel.keep.lists@gmail.com> wrote:
>>> Sorry, but you can't seriously claim D is still easy to implement whilst .stringof still exists in its current form.  :P
>>
>> Oh, .stringof is nothing compared to the complexity added by string mixins ;)
>>
>> Or some of the scarier parsing issues.  (Type).Identifier and the (int
>> x) { return x + 5; } delegates are two things that come to mind..
>
> What's up with the last two? I haven't quite gotten to them in semantic yet, but I didn't notice any problems in parsing them

(Type).Ident is one case of many in the D grammar where you don't actually know whether to parse something as a type or as an expression.  You just have to parse it as an indeterminate form and resolve the ambiguity in the semantic phase.  For instance, in (Foo).bar, Foo can be either a type or an expression.  You also have to perform lookahead in order to be able to tell whether or not it might be parseable as a type.  All sorts of things look like both types and expressions: x[], x[5], x[y], T!(x), typeof(x).y, x.y, etc. Other cases where the type-expression ambiguity exists is in template argument lists (since template arguments can potentially be an arbitrary mix of types and expressions) and the key type of associative array types.  Grep the DMDFE sources for 'toExpression' and 'toType' and you'll see how it resolves this ambiguity.

The amount of lookahead you need is also frankly disturbing.  This, for instance:

Foo[typeof(function void() {
    // imagine 300 lines of code here.
    // no one sane would do this, but it's possible.
})] x;

This declares an associative array.  You have to lookahead 300 lines to be able to tell that yes, this really is an AA declaration.  Add a .blah after the typeof() and suddenly you don't actually know whether it is or not!

As for the (int x) { return x + 5; } syntax, it's not quite as terrible, but still annoying.  It means to have to lookahead on every open-paren that isn't parsed as a call expression to see whether or not it's a delegate literal.  Grep DMDFE for 'peekPastParen'.

Jarrett Billingsley wrote:
> On Tue, Jul 28, 2009 at 2:43 AM, Ellery Newcomer<ellery-newcomer@utulsa.edu> wrote:
>> Jarrett Billingsley wrote:
>>> On Thu, Jul 23, 2009 at 10:23 PM, Daniel Keep<daniel.keep.lists@gmail.com> wrote:
>>>> Sorry, but you can't seriously claim D is still easy to implement whilst .stringof still exists in its current form.  :P
>>> Oh, .stringof is nothing compared to the complexity added by string mixins ;)
>>>
>>> Or some of the scarier parsing issues.  (Type).Identifier and the (int
>>> x) { return x + 5; } delegates are two things that come to mind..
>> What's up with the last two? I haven't quite gotten to them in semantic yet, but I didn't notice any problems in parsing them
> 
> (Type).Ident is one case of many in the D grammar

Well, you've just sapped my resolve to continue. You wouldn't happen to have a list of these things somewhere, would you?

Come to think of it, am I missing anything about stringof? It looks to me like contradictory requirements; on one hand spec mandates no semantic analysis, on the other you need to determine if stringof is a field reachable by dot. And the compiler goes with the latter.

On Wed, Jul 29, 2009 at 2:01 AM, Ellery Newcomer<ellery-newcomer@utulsa.edu> wrote:
>
> Well, you've just sapped my resolve to continue. You wouldn't happen to have a list of these things somewhere, would you?

What I've listed in my post is most of it.  :)

> Come to think of it, am I missing anything about stringof? It looks to me like contradictory requirements; on one hand spec mandates no semantic analysis, on the other you need to determine if stringof is a field reachable by dot. And the compiler goes with the latter.

That sounds like a bug to me.  The compiler really should disallow redefining built-in properties, and it does for some (try defining a 'sizeof' member), but not others.  (Of course I find the whole property syntax used for type introspection a bit silly, a half-thought-out feature that's hard to parse, not easily extensible, and which doesn't fit syntactically with the rest of the metaprogramming facilities.)

Wed, 29 Jul 2009 08:58:32 -0400, Jarrett Billingsley thusly wrote:

> (Of course I find the whole property
> syntax used for type introspection a bit silly, a half-thought-out
> feature that's hard to parse, not easily extensible, and which doesn't
> fit syntactically with the rest of the metaprogramming facilities.)

Maybe it requires a better grasp of the big picture to fully understand the nuances involved? After all, a feature like object.stringof is much easier to type than the other alternative __traits (get_string_presentation_of, object)

On Wed, Jul 29, 2009 at 9:43 AM, language_fan<foo@bar.com.invalid> wrote:
> Wed, 29 Jul 2009 08:58:32 -0400, Jarrett Billingsley thusly wrote:
>
>> (Of course I find the whole property
>> syntax used for type introspection a bit silly, a half-thought-out
>> feature that's hard to parse, not easily extensible, and which doesn't
>> fit syntactically with the rest of the metaprogramming facilities.)
>
> Maybe it requires a better grasp of the big picture to fully understand the nuances involved? After all, a feature like object.stringof is much easier to type than the other alternative __traits (get_string_presentation_of, object)

Or it's just that Type.property was in the D spec as early as 1999, and D wasn't initially meant to have metaprogramming, so its various introspection capabilities are kind of .. organically grown.

__traits is ugly only because W wanted it to be.  traits(stringof, x) is just as easy to type, far easier to parse, and much more consistent than x.stringof.

Wed, 29 Jul 2009 09:55:40 -0400, Jarrett Billingsley thusly wrote:

> so its various
> introspection capabilities are kind of .. organically grown.
> ...
> __traits is ugly only because W wanted it to be.

Good points.. that could also be the case. Now that the D 2.0 specification has not been frozen yet, supposedly these kinds of issues could be solved before it is too late?