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