From: david.brown@hesbynett.no
On 29/11/2025 15:40, bart wrote:
> On 29/11/2025 13:45, David Brown wrote:
>> On 29/11/2025 12:24, bart wrote:
>>> On 29/11/2025 03:38, Keith Thompson wrote:
>>>> bart writes:
>>>>> On 28/11/2025 23:23, Keith Thompson wrote:
>>>>>> bart writes:
>>>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>>>>>> [...]
>>>>>>>> You can of course add as many commodity features to "your language"
>>>>>>>> as you like. I seem to recall that one of the design principles of
>>>>>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>>>>>>>> a function or keyword above [in "your language"].)
>>>>>>>
>>>>>>> It is a reserved word, which means it can't be used as either a
>>>>>>> top-level user identifier, or a member name. With extra effort, it
>>>>>>> could be used for both, but that needs some special syntax, such as
>>>>>>> Ada-style "A'odd"; I've never got around to it.
>>>>>>>
>>>>>>> In Pascal (where I copied it from) it is a reserved word.
>>>>>> In Pascal, "odd" is not a reserved word. It's the name of a
>>>>>> predefined function.
>>>>>
>>>>> So what's a 'reserved word' then? To me it is something not available
>>>>> as a user-identifier because it has a special meaning in the language,
>>>>> which may be that of a predefined function among other things.
>>>>
>>>> Right. The name "odd" is available as a user-defined identifier.
>>>> If you define something named "odd" in Pascal, it hides the
>>>> predefined function of that name.
>>>
>>> I did test it with a toy Pascal compiler I have. Defining 'odd' as a
>>> variable didn't work, but that was for other reasons.
>>>
>>>
>>>> You can think of Pascal's predefined functions as being declared
>>>> in an outer scope, surrounding the main program.
>>>
>>> I took 'predefined functions' to mean 'built-in
>>> functions' (effectively, operators with function-like syntax), that
>>> cannot be overridden.
>>>
>>> So 'odd' is not a reserved word in Pascal; I was mistaken.
>>>
>>> (My opinion is that being able to shadow fundamental language
>>> features is undesirable. Being able to reuse them as user identifiers
>>> is another matter, but that would involve tricks with syntax or
>>> context to avoid ambiguity.)
>>>
>>>
>>
>> The issue is where you draw the line of what is a "fundamental
>> language feature", and what is not. For Pascal, "begin" is a
>> fundamental language feature, part of the syntax. "odd" is not
>> fundamental - it's just a function in the Pascal's equivalent of the C
>> standard library. So no tricks or special syntax (like "stropping")
>> are needed to re-use the identifier for other purposes.
>>
>> I agree that using words that are "fundamental" is not good. But if a
>> language provides built-in functions in a global namespace, then it is
>> a serious limitation if these cannot be shadowed or overridden.
>
> I see it as an advantage. I can do this in Python:
>
> len = 42
> print(len("abc"))
>
> Now len() no longer works as expected. In Algo68 you can do this:
>
> OP + = (INT a, b)INT: a - b;
> print(2 + 3)
>
> This prints -1. (Or, more subtly, you can redefine the precedence of '+'
> to be the opposite side of '*'.)
>
> With different scopes in effect, different parts of a program can see
> different versions of what many might not realise are user-overrideable
> features.
>
I am not suggesting it is a good idea for a program to knowingly re-use
an identifier that is commonly used in the language for other things.
But sometimes there is a collision. The folks adding new functions or
features to a language or library do not usually know of all uses of
identifiers in existing code.
>
>> Basically, it means that you are always at risk of conflicts with
>> existing code if later language versions add new functions. So if
>> someone wrote Pascal code with a local variable called "even", and a
>> later version introduced a built-in function "even", then it is
>> critical that this is an overrideable or shadowable (if that is a real
>> word!) identifier.
>
> If 'even' is implemented as though it can be defined via a user-
> function) then shadowing is normally allowed (unless the language likes
> to warn you about such things).
>
> But if it's a true built-in that just happens to use function syntax,
> then the user sees an error. Then they can choose to update their
> codebase, when possible.
A choice between changing the codebase, or only being able to use old
tools or old language version is not a good choice for users.
Most modern languages support some kind of namespace, which solves this
problem. In C++, new functions are added to the std:: namespace which
will never be in conflict with user identifiers. Some of these will be
very similar to "true built-ins" in that the functions cannot be written
in the language itself, but require some kind of "compiler magic" to
work. That's okay - it doesn't matter to the user. (Behind the scenes,
a compiler might have the actual builtin with a secret name that users
should never see.)
>
> For somebody else's code, or for legacy code, that becomes harder, and
> the implementation may need to strictly enforce language versions so
> that such new features are disabled via the build info.
>
> Alternately, such built-ins can use special syntax so they would never
> clash with user-identifiers.
Namespaces are ideal for this. It's such a useful feature that it
should be available to users and third-party library writers, not just
the language and its standard libraries.
>
> Note that such clashes can also occur when mixing libraries: maybe both
> library A and B can export 'even', even when everything is defined in
> user-code.
>
Yes. No solution is ever going to prevent all identifier clashes. But
you can go a fair way to reducing the risk.
> Then the language had better have a namespace feature to disasmbiguate
> (which I have, but C doesn't)
>
Indeed. It's a serious limitation in C, and one reason for people
switching to C++. (Some people use C++ as "ABC" - "A better C". They
use namespaces, better "const", and a few other features, while avoiding
what they consider complex or potentially inefficient features.)
>
>> That's why C is very conservative about adding new keywords, and uses
>> reserved namespaces for the purpose - thus C99 added "_Bool", not
>> "bool", to avoid conflict with existing code. Only now, over two
>> decades later, did the committee feel that uses of the identifier
>> "bool" other than as a typedef for _Bool (usually via ) are
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
