From: david.brown@hesbynett.no   
      
   On 27/11/2025 13:20, bart wrote:   
   > On 27/11/2025 10:43, David Brown wrote:   
   >> On 26/11/2025 23:19, bart wrote:   
   >   
   >   
   >> What I don't like about your bit extraction operations is that you   
   >> have an operator syntax for a fairly obscure and rarely used operation.   
   >   
   > So shift and masking operations in C are obscure?!   
      
   Both shift operators and bitwise operators have lots of other uses.   
      
   When you are designing a programming language, you first provide general   
   features that can be used for multiple purposes.  You only implement   
   specialised features if the need arises - it is too cumbersome, or   
   error-prone, or inefficient, or laborious to use the general features.   
      
   In some areas of C usage, shifts and masks - and bitfield extraction -   
   turn up quite a bit.  But it seems the C operators work fine for the   
   task.  It would not exactly be difficult to add a standard   
   "bit_range_extract" function to the C standard library, yet no one has   
   felt it to be worth the effort over the last 50 years.  Perhaps it is   
   not as essential or fundamental as you think?  Or perhaps C's current   
   features do the job well enough that there's no need for anything else?   
      
   >   
   >    A   
   >> "bit_range_extract" standard library function would make more sense to   
   >> me, though I think shifting and masking works well enough for the few   
   >> situations where you need it.  A syntax that looks very much like   
   >> array access is not going to be helpful to people looking at the code   
   >> - for general-purpose languages, most programmers will never see or   
   >> use bit ranges.   
   >   
   > The syntax actually comes from DEC Algol60 IIRC. It was used to access   
   > individual characters of a string, normally an indivisible type in that   
   > language, and I applied the same concept to bits of an integer.   
      
   I don't care if you found the syntax on the back of a cornflakes packet.   
     The origin is not relevant.   
      
   >   
   >>> How much more fundamental can you get?   
   >>   
   >> It is not fundamental for a low-level systems language.   
   >   
   > So bits are not fundamental either! But then, it has taken until C23 to   
   > standardise binary literals, and there is still no format code for   
   > binary output.   
   >   
      
   Very few programmers are at all interested in bits.  A "double" holds a   
   floating point value, not a pattern of bits.  You are thinking on a   
   level of abstraction that is not realistic for most programming tasks.   
      
   >>>>   But the people who write those are few, and they know what they   
   >>>> are doing.)   
   >>>   
   >>> And I don't? I used to write FP emulation routines...   
   >>>   
   >>   
   >> The thing you always seem to forget, is that your languages are   
   >> written for /you/ - no one else.  It doesn't make a difference whether   
   >> something is added /to/ the language or written in code /for/ the   
   >> language.  You think other languages are missing critical features   
   >> simply because there is a thing that /you/ want to do that you added   
   >> to your own language. And you think other languages are overly complex   
   >> or bloated because they have features that you don't want to use.   
   >   
   > They frequently have advanced features while ignoring the basics.   
      
   No - they frequently have features that /you/ call "advanced" because   
   you don't need or want them, and they ignore things that /you/ call   
   "basics" because you /do/ need or want them.  It's all about /you/.   
      
   >   
   >> Imagine asking the regulars in this group what features or changes   
   >> they would like C to have in order to make C "perfect" for their uses,   
   >> regardless of everyone else, all existing code, all existing tools.   
   >> We could all fill pages with ideas.  And if those were all added to C,   
   >> the result would be a language that made C++ look as easy as Logo,   
   >> while being riddled with inconsistencies and contradictions.   
   >   
   > Yes, that's the trick. That's why a lot of features I've played with   
   > have disappeared, while some have proved indispensable.   
   >   
   >>> As it is, somebody using C as an intermediate language can have a   
   >>> situation where something is well-defined in their source language,   
   >>> known to be well-defined on their platforms of interest, but   
   >>> inbetween, C says otherwise.)   
   >>   
   >> You've never really understood how languages are defined, have you?   
   >> With your own languages and tools, you don't have to - there is no   
   >> need for standards, specifications, or anything like that.  You can   
   >> just make up what suits you at the time.  The language is "defined" by   
   >> what the implementation does.  That's been very convenient for you,   
   >> but it has left you with serious misconceptions about how non-personal   
   >> languages work.   
   >   
   > Here's a  program in a very simple language, where all variables have   
   > i64 type:   
   >   
   >    c = a + b   
   >   
   > Here, the author has decreed that any overflow in this addition will   
   > wrap (any overflow bits above 64 are lost). If directly compiled to x64   
   > code it might use this (here 'a b c' are aliases for the registers where   
   > they reside):   
   >   
   >      mov c, a   
   >      add c, b   
   >   
   > Or on ARM64:   
   >   
   >      add c, a, b   
   >   
   > Now, the author decides to use intermediate C (for portability, for   
   > optimisations etc), and will generate perhaps:   
   >   
   >      int64_t a, b, c;   
   >      ...   
   >      c = a + b;   
   >   
   > But here, if a + b happens to overflow, it is UB, and for no good   
   > reason. You have to fix it. This is where it can be harder to generate   
   > HLL code than assembly!   
   >   
      
   You are talking nonsense.   
      
   Either a + b results in the correct answer, or it does not.  Any sane   
   person reads that as "a plus b" - mathematically adding two integers to   
   get their sum.  That's what the programmer wants, and that's what they   
   ask for.  And any sane programmer expects the language to give the   
   correct result within its limitations, but doe not expect it to do   
   magic.  Expecting to form a sum that is greater than 2 ^ 63 and somehow   
   produce the "correct" result is a total misunderstanding of mathematics   
   and programming - any primary school kid will tell you that using the   
   fingers of one hand, you can't add 3 and 4.  They will /not/ tell you   
   that it's fine to add them on one hand because 3 + 4 is actually equal to 2.   
      
   > *Now* do you understand? This is nothing to do with me or my personal   
   > languages, it is a problem for every language that transpiles to C,   
   > where there is a mismatch between the sets of behaviour considered UB in   
   > each.   
      
   I understand that simple maths and common sense is beyond you.  I   
   understand that you think mathematics should be defined in terms of   
   accidental byproducts of the way hardware logic designs happen to be   
   implemented.   
      
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)