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

[Jarrett Billingsley]

On Tue, Jul 28, 2009 at 2:43 AM, Ellery
Newcomer<ellery-newcomer at utulsa.edu> wrote:
> Jarrett Billingsley wrote:
>> On Thu, Jul 23, 2009 at 10:23 PM, Daniel
>> Keep<daniel.keep.lists at 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'.