From: bc@freeuk.com   
      
   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.   
      
      
   > 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.   
      
   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.   
      
   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.   
      
   Then the language had better have a namespace feature to disasmbiguate   
   (which I have, but C doesn't)   
      
      
   > 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 so rare   
   > that C23 could finally have "bool" as a keyword for the type.  And they   
   > still have challenges with good names for standard library functions -   
   > now in C23, many new ones have names with a "stdc_" prefix.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)