From: already5chosen@yahoo.com   
      
   On Thu, 27 Nov 2025 14:02:38 +0100   
   David Brown  wrote:   
      
   > 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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)