Revised RFC on range design for D2
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Oct 2 05:48:25 PDT 2008
Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Benji Smith wrote:
>>> Andrei Alexandrescu wrote:
>>>> 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.
>>>
>>> I'd like to propose another principle of language design:
>>>
>>> 3) Consistency -- The expression of a semantic construct should
>>> always use the same syntax. Likewise, multiple uses of the same
>>> syntactic constructs should always result in the same semantics.
>>
>> Consistency is good, but that's not consistency.
>>
>> http://www.merriam-webster.com/dictionary/consistency
>>
>> agreement or harmony of parts or features to one another or a whole :
>> correspondence ; specifically : ability to be asserted together without
>> contradiction
>>
>
> The concept of "consistency" has a more specialized meaning when applied
> to language design. (just has it has in other fields, like mathematics)
> So I agree with benji that not having "The expression of a semantic
> construct should always use the same syntax" is not being consistent.
> (There are of course other situations where things can be inconsistent.)
No. Not at all. For consistency you must assert together something with
something else. If there are two possible and equivalent syntaxes for a
feature that's not lack of consistency. It's waste. We'd be talking
about consistency if at most "syntax in context A should be the same as
syntax in context B". But if the context is irrelevant to the syntax
then we're not quite talking about consistency.
Let me give another example. One could say in C++ overloading template
functions is inconsistent with overloading regular functions because
they follow very different rules. The fact that in C++ you can specify
either "class" or "typename" for a template parameter is NOT
inconsistent. It is wasteful.
> If you don't agree with this definition of "consistency", I'm not gonna
> argue with that , just substitute it with "conzistency" or "foobar", or
> whatever and proceed.
No. Defining terms is important. If we have the wrong terms in mind when
talking about something, communication is impeded.
>> An example of consistency is that user-defined operators have the same
>> syntax and precedence as built-in operators.
>>
>>> Based on that principle, I'd argue that function-calling should
>>> either always use parentheses, or it should never use parentheses.
>>
>> Yah I'd like that too. It's economy of syntax.
>>
>
> Then why are you not suggesting, or campaigning for, such change?
Because language design is putting many desiderata in agreement, not
following one blindly.
>>> Requiring parentheses for some function calls, but not for others
>>> violates the principle of consistency.
>>
>> No. It violates economy of syntax. There are many syntaxes for the same
>> semantics.
>
> It violates consistency, as defined above.
No. You can't define a term to mean whatever you want. I mean you can,
but then it's hard to communicate.
> It may violate economy of
> syntax as well (or it may be the same thing). Whatever. What I ask is,
> what would you suggest to fix it? Should all function calling not use
> parenthesis? And how would that syntax be?
I'm happy with how things are now except for the assignment that is
accepted all to often. I suggested a simple fix for that.
Andrei
More information about the Digitalmars-d-announce
mailing list