Revised RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> Hidden in this statement is that you consider () to be semantically 
>>> meaningless.  I see it not as meaningless, but a distinction between what 
>>> the symbol is supposed to represent.  A property should represent a 
>>> value. A function should represent an action.
>> Sheesh, do I really need to spoonfeed all of this? First I mentioned the 
>> principles I quoted above. Then I clearly explained how C's handling of 
>> function names breaks these principle, with examples. Please refer to that 
>> post. There is nothing hidden my statement.
> 
> Sorry, I look at things more simply, and I'm not really into language design 
> theory ;)  I didn't realize that calling something a principle meant that it 
> is generally accepted to be fact, my apologies.
> 
> So I should read your statement as:
> 
> "a principle that is generally accepted to be universally true by major 
> language design geeks, that I also agree with, is..."
> 
> I'm not trying to be clever here, I really didn't understand that it was 
> implied.

No, you shouldn't read it that way. (Explanation below.)

> So I agree with your principle, just not that () falls within the category 
> of 'pragmatically or semantically meaningless.'

I'd also disagree with that, and I never said that either. What I said 
was that in C use of a function name alone is syntactically valid, 
semantically a no-op, and consequently pragmatically meaningless.

> I'd also disagree that the most frequently used construct of calling a 
> function is without parentheses.

I'd also disagree with that, and I never said that either. My perception 
is that there is a serious "barrier in miscommunication" out there. What 
I said was that the most frequent use of a function is to call it. 
Therefore it is a pity that mentioning its name not only does not call 
it, but in fact does nothing.

>>> I'll also note that your basis/proof is not any more proof than mine ;) 
>>> You just made statements about what you believe, as did I.
>> The note is wrong. I provide the principles as basis. Then I provide proof 
>> using that basis. If you want to invalidate that, you need to invalidate 
>> my basis, i.e., the principles of language design I am invoking. You are 
>> of course free to do that since principles of programming language design 
>> are to large extent a subjective matter.
> 
> Not really.  You provided no proof that your principles apply to this 
> debate, you just stated that they do.

No, you don't understand. Let me explain again.

I stated two principles of language design. They could be true or false. 
They are up there for debate. They are subjective, because aside from 
some basics, language design is subjective.

The principles are:

1) A language should minimize the number of syntactic constructs that 
are semantically and/or pragmatically meaningless.

2) The more frequently-used constructs should be given syntactic 
priority over the less-used constructs, particularly when the latter are 
also at risk of breaking the first principle.

Then based on the principles I explained how C's use of function names 
breaks them in the post on Thu, 25 Sep 2008 22:59:04 +0000 (UTC). It's 
easy, really.

>>> Sorry, change my statement to 'But it makes sense and still does'.  And I 
>>> never said it was a proof.  It's a statement of my reasons behind 
>>> believing the () decision was on purpose.
>> The decision was on purpose, I am sure it wasn't an oversight. It was a 
>> poor decision because it breaks the aforementioned principles.
> 
> Respectfully disagree.

Now you either disagree with the principles, the consequences, or the 
way the consequences derive from the principles. My understanding is 
that the problem is with the latter. Again I am referring you to that 
same post.

>>> Not really.  A function symbol by itself is the address of the function. 
>>> A pointer symbol by itself is the address of the data it points to.  It's 
>>> the same.  I don't think you understood the detail that I stated, 'get 
>>> address it's pointing to', not 'get address of the pointer'.
>> I understood very well. Your point is off by a mile, and getting only 
>> farther. Please understand how you are making an elementary mistake.
>>
>> Consider:
>>
>> int x;
>>
>> Then if I only use "x", I am getting x's value (an lvalue in fact), not 
>> its address. Now consider:
>>
>> int * x;
>>
>> Then if I only use "x", I am getting x's value, which is the address of an 
>> int.
>>
>> In neither case is it possible for x and &x to mean the same thing. For 
>> functions some really weird stuff happens:
>>
>> // this is C
>> #include <assert.h>
>> void foo() {}
> 
> How does this make any difference to whether you can call a function without 
> parentheses or not?  You are arguing that for a function defined as foo(), 
> foo; should mean call function foo, and I'm arguing that it should be a 
> syntax error.  Neither of us want the C behavior of evaluating to the 
> function address.
> 
> I think &foo should be the proper method of taking the address of a 
> function, as it is in D.

I am glad this partially took care of itself.

Andrei