From: janis_papanagnou+ng@hotmail.com   
      
   On 2025-11-30 13:51:22, bart wrote:   
   > On 30/11/2025 04:31, Janis Papanagnou wrote:   
   >> On 2025-11-30 03:30:42, bart wrote:   
   >>> On 30/11/2025 00:46, Keith Thompson wrote:   
   >>>> bart  writes:   
   >>>>> You can have general _BitInt(N) syntax and have constraints on the   
   >>>>> values of N, not just an upper limit.   
   >>>>   
   >>>> No you can't, because the language does not allow the arbitrary   
   >>>> restrictions you want.  If an implementer finds _BitInt(1187)   
   >>>> too difficult, they can set BITINT_MAXWIDTH to 64.   
   >>>>   
   >>>> One more time: Both gcc and llvm/clang have already implemented   
   >>>> bit-precise types, with very large values of BITINT_MAXWIDTH.   
   >>>> What actual problems has this fact caused for you, other than giving   
   >>>> you something to complain about?   
   >>>   
   >>> What problem would there be if BitInt sizes above the machine word   
   >>> sizes had to be multiples of the word sizes?   
   >>   
   >> Not sure whether you're talking at cross-purposes. (I haven't   
   >> followed all postings or details.)   
   >>   
   >> If, on a 64-bit-word system, _BitInt(80) would produce an error   
   >> (because it "had to be multiples of the word sizes", as you say),   
   >> that would obviously be a problem, don't you think?   
   >   
   > How did you represent an 80-bit type up to now? How much of a problem   
   > has it actually been?   
      
   I had to use workarounds and/or more effort to achieve what I intended.   
   For the implementation I have to think in terms of technical entities   
   unnecessarily, and not in [more natural] application domain entities.   
      
   >   
   >>> It what way would it inconvenience /you/?   
   >>   
   >> If I couldn't define _BitInt(80) I'd indeed consider that a problem.   
   >> Or any other constant value that stems from my application domain.   
   >   
   > Which domain is that, is it representing, as an integer, the 80-bit   
   > float type from an x87 FPU?   
      
   That was an arbitrary number. (Other posters provided extensive lists   
   of other numbers already, based on application domain requirements.)   
      
   I could provide even more "crude" numbers, say, like _BitInt(17), to   
   operate on coefficients of generator polynomials, just for example.   
   The point is not to discuss any specific number. - The point is that   
   they are bound to the application domain and express a sensible (not   
   artificial, defined by technical CPU word-sizes) counterpart of the   
   [application domain] items you work on.   
      
   Programming is about implementing solutions to application problems.   
   It's not primarily about focusing how the hardware looks like. There   
   are abstracting formal programming languages (and the compilers) that   
   shall bridge that gap as good as possible. (To be clear; "C" hadn't   
   been a good paragon concerning that abstraction capability.) We're   
   using computers primarily to work on real-world tasks (not to engage   
   existing hardware with work of any sort).   
      
   The fact that you obviously don't see that, and also don't understand   
   it after pointing that out, in addition with your squirming to *not*   
   *answer* the repeatedly formulated question what your actual problem   
   with it is, that all shows that you are obviously not willing to be a   
   serious discussion partner.   
      
   >   
   >>>   
   >>> So I'm interested in what that one extra bit in a million buys you.   
   >>> Or that one bit fewer.   
   >>   
   >> It's not about extra bits. It's about making it possible to define   
   >> what your tasks (that are to be implemented) ask for. (In my book.   
   >> YMMV.)   
   >   
   > Yet over the past decades nobody has been screaming because they   
   > couldn't have a 31-bit or 65-bit numeric type. But now suddenly EVERYONE   
   > wants to be able to do that, and on huge numbers!   
      
   You are again talking nonsense and exposing your non-sincere moves   
   to stupidly exaggerate ("screaming") and unreasonable generalize   
   ("EVERYONE"). - Yet, you prove again that you are not willing to   
   be a serious discussion partner.   
      
   >   
   > I think there's more psychology at play here than anything else.   
      
   It's okay to have opinions. - If that's all you want to share, your   
   opinions and personal preferences, that's okay.   
      
   But it's not okay to strip, repeatedly ignore, and not answer the   
   basic repeatedly asked question:   
      
    >> What actual problems you have (or could imagine) with that?   
      
   Why are you so stubbornly refusing to answer that? - I'll tell you;   
   because it would expose that you have nothing to contribute but an   
   isolated opinion from your extremely restricted bubble of thinking.   
      
   You have a chance to answer now!   
      
   (Or will you instead yet again complain about the personal attacks?)   
      
   Janis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)