Revised RFC on range design for D2

Steven Schveighoffer schveiguy at yahoo.com
Mon Sep 29 12:51:10 PDT 2008


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

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

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

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

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

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

-Steve 




More information about the Digitalmars-d-announce mailing list