Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> 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.
> 

I wasn't talking about the two cases of calling a zero-args function 
with parenthesis, and calling it without parenteshis (the "two possible 
and equivalent syntaxes for a feature"). That's not inconsistency, it's 
waste, I agree.
I was talking about the two cases of calling a zero-args function 
("context A"), and a n-args function ("context B"). So here we can talk 
about consistency, like you defined: "syntax in context A should be the 
same as syntax in context B". As such, the syntax for both cases is more 
consistent if they both use parenthesis.

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

I agree.

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

I don't get it. What other desiderata are in conflict? Those of other 
people, or other desiderata of your own? Because when you say "I'd like 
that too", I read that as meaning that, at least for your own, you would 
prefer if such change was implemented. (ie, weighting all your concerns, 
you still prefer the change)

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

By "some functions" I meant n-args functions, and by "others" I meant 
zero-args functions. That gives: "[Putting] parenthesis for n-args 
function calls, but not for zero-args function calls violates the 
principle of consistency."
So we go back to the first point in this post.

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

I don't understand that. You stated "It violates economy of syntax.", so 
  it violates your Principle 1 of language design. So how can you be 
happy with that (apart from the assignment issue)? Does fixing this 
problem violate some other principle or concern of yours?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D