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
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 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
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 reply 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=






t

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


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




ns ;)

 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
parent reply 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


 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.
Jul 28 2009
parent reply 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
parent reply 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
parent reply 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
parent reply 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
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