Steve Yegge's rant on The Next Big Language

Sean Kelly sean at f4.ca
Mon Mar 12 11:29:28 PDT 2007


Frits van Bommel wrote:
> 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? :) )

No, I was merely thinking of the syntax in general rather than 
specifically in a function call.  For example, I believe this is legal:

(int x) {printf("%d\n", x); }( 2 );

> 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.

In the context of a function call, I agree.

> 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.

Yup :-)


Sean



More information about the Digitalmars-d-announce mailing list