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