equivariant functions

[Yigal Chripun]

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.