www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [~OT] Finally, a clear, concise D spec!

reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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 ;)
Jul 23 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Jul 23 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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
Jul 27 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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

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

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.
Jul 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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. =A0: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..
Jul 23 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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 whils=



 .stringof still exists in its current form. =A0:P

Oh, .stringof is nothing compared to the complexity added by string mixi=


 Or some of the scarier parsing issues. =A0(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'.
Jul 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.)
Jul 29 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
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)
Jul 29 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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.
Jul 29 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
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?
Jul 29 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Jul 29, 2009 at 10:03 AM, language_fan<foo bar.com.invalid> wrote:
 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?

In theory, yes. In reality, probably not.
Jul 29 2009