Steve Yegge's rant on The Next Big Language

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>>
>> I just thought of a semi-ambiguity. If the return type and the types 
>> of any parameters are user-defined, and all parameters (if any) are 
>> anonymous and implicitly 'in', the first part looks just like a 
>> function call: "foo(bar)" can then be either a call to a function 
>> 'foo' with parameter 'bar', or the start of a delegate returning a 
>> value of type 'foo' taking an anonymous parameter of type 'bar'.
> 
> It could also look like an object instantiation via static opCall 
> followed by a nested block of code.  Excluding the separating semicolon, 
> of course.

A static opCall is also a regular function as far as the syntax is 
concerned, just one that happens to have the same name as an aggregate 
type. AFAIK the compiler doesn't even generate different code for this 
(except for the actual function address concerned, of course). A 
non-static opCall is slightly different here, but should AFAIK generate 
code equivalent to a that of a delegate call, except the function is a 
constant instead of stored in memory.

See below regarding the semicolon.

>> But since IIRC D already requires an infinite-lookahead parser, the 
>> next character (either a '{' or not) should disambiguate, which is why 
>> I only called this a semi-ambiguity.
> 
> Yup.
> 
>> Can anyone think of an actual ambiguity, or think of another reason 
>> this is not allowed? Barring fault, oversight or laziness (or perhaps 
>> just busy-ness) on Walter's part, of course :P.
> 
> I think the presence or lack of a semicolon keeps this from being a true 
> ambiguity.

No, I think it's the presence of an opening brace, not a semicolon; for 
instance, it's still a function call if the next token is some sort of 
binary operator ('+', '*', '/', '.', whatever): in the expression 
"foo(bar) + 5" the "foo(bar)" must be a function or delegate call of 
some sort. (Perhaps you failed to consider that functions are allowed to 
return values? :) )
So the absence of a semicolon doesn't mean it's not a function call, 
whereas the absence of an opening brace does mean it's not a delegate 
literal. So the opening brace would be the superior discriminating 
token, since its presence also unambiguously (AFAICT) indicates a 
delegate literal.

But as I immediately indicated, I agree that this isn't a real ambiguity 
(and that it was just the closest thing to one I could come up with :) 
). Which I consider to be a good thing, as I'm hoping there isn't any 
ambiguity and this syntax can therefore be allowed in a future D version.