equivariant functions

[KennyTM~]

Yigal Chripun wrote:
> KennyTM~ wrote:
>> Andrei Alexandrescu wrote:
>>> Jason House wrote:
>>>> Andrei Alexandrescu Wrote:
>>>>
>>>>> ore-sama wrote:
>>>>>> Andrei Alexandrescu Wrote:
>>>>>>
>>>>>>> typeof(s) stripl(const(char)[] s);
>>>>>>>
>>>>>>> This signature states that it returns the same type as an
>>>>>>> argument. I propose that that pattern means stripl can accept
>>>>>>> _any_ subtype of const(char)[] and return that exact type.
>>>>>>> Inside the function, however, the type of s is the type
>>>>>>> declared, thus restricting its use.
>>>>>> this conflicts with current definition of typeof. Currently
>>>>>> typeof(s) stripl(const(char)[] s); should be interpreted exactly
>>>>>> as const(char)[] stripl(const(char)[] s); it's unclear that
>>>>>> typeof here gets type of actual argument rather than parameter.
>>>>>> Currently typeof applies to parameter.
>>>>> That is correct.
>>>>>
>>>>> Andrei
>>>> I've never understood the reuse of keywords for new meanings. I much
>>>> prefer new keywords for new concepts.
>>> Even in natural language identical words are reused for various
>>> different meanings. This suggests that people would not feel
>>> comfortable with a very large vocabulary. The size of vocabularies
>>> varies dramatically, but if you look closer you'll see that languages
>>> with large vocabularies tend to have simpler grammars, suggesting that
>>> a language's overall complexity is a constant-sum game.
>>>
>>> In programming languages growing the vocabulary indiscriminately is
>>> worse because it chews into the vocabulary available to user-defined
>>> symbols.
>>>
>>> Also, whenever a feature is to be integrated into the language, it is
>>> preferable if possible to integrate it under an existing concept
>>> instead of "allocating" a new concept to it.
>>>
>>>
>>> Andrei
>> Yes. That makes foreign English learners confusing the many uses of
>> prepositions.
>>
>> I think a programming language should not be like a natural language,
>> but it must be precise enough to reduce ambiguity as much as possible.
>> Overloading keywords with entirely different meaning is no good (scope,
>> static, invariant).
>>
>> (I think this is OK to use typeof in this feature, since you're really
>> getting a type of something.)
>>
>> -
>>
>> BTW, the keyword problem exists because we chose to use /[_a-z]\w*/ to
>> represent identifiers, which coincide with keywords. Perl and PHP, for
>> example, uses /[$@*%][_a-z]\w*/ to represent variables, so the keyword
>> problem can be somewhat diminished. Of course I'm not asking you to
>> adopt this, as I hate those sigils too, but I'm just saying adding
>> keywords can leave user identifiers alone.
> 
> if I remember correctly, C# allows you to use keywords as identifiers.
> for example:
> int @if = 5;
> 
> the @ tells the parser not to treat "if" as a reserved word. I don't
> know how much that feature is actually being used but having a way to
> escape keywords like that also solves the problem.

int _if = 5;

The problem Andrei stated is not existing keywords chewing the 
vocabularies I believe, but *new* keywords chewing the vocabularies.

But I also think that there are some "universal keywords" that a good 
programmer should avoid using as an identifier, e.g. "define", 
"implements" etc. so you're free to use, though it could also be quite 
subjective.