From: david.brown@hesbynett.no   
      
   On 26/11/2025 16:44, bart wrote:   
   > On 26/11/2025 14:49, David Brown wrote:   
   >> On 26/11/2025 13:05, bart wrote:   
   >>> On 26/11/2025 07:55, David Brown wrote:   
   >   
   >>>> NIH syndrome combined with megalomania.  Other people do this stuff   
   >>>> better than you.   
   >   
   >>> I made a decision to keep my systems language at a certain level   
   >>> regarding such things as the type system, while having lots of   
   >>> convenient micro-features:   
   >>>   
   >>>      print int@(x+y).[52..62]   
   >>>   
   >>> This type-puns a float64 r-value expression into an int, and extracts   
   >>> that bitfield (which is the unsigned exponent field when float64 uses   
   >>> iee754).   
   >>>   
   >>> I'd be interested to see how you can do this better, using general   
   >>> language features (adding a dedicated .exponent property to floats   
   >>> would be cheating!).   
   >>>   
   >>   
   >> What an absurd thing to ask for.   
   >   
   > You said, "Other people do this stuff better than you". Presumably,   
   > devising language features. So I gave an example of a small task, and   
   > asked which features those people would devise, or what solution they   
   > would use.   
   >   
      
   The "other people" I referred to are the folks behind the C language,   
   not me.   
      
   >>   You have a special feature in your language for writing obscure   
   >> things that are rarely if ever useful in normal coding.   
   >   
   > Yes, I call them 'micro-features'.   
   >   
   > The examples showed rvalue type-punning and bitfield extraction, which   
   > were recent examples in this thread.   
   >   
   > In C, the solution for my example might look like this:   
   >   
   >      double temp = x+y;   
   >      printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);   
   >   
      
   No, that's not how a C solution would work.  People who know C would   
   know that.  As a challenge for you, see if you can spot your mistake.   
      
   (And of course if anyone wanted to do this stuff in real code, they'd   
   wrap things in a static inline "bit_range_extract" function.)   
      
   > Rather more fiddly and error prone, and it needs an auxiliary statement   
   > that makes it awkward to embed into an expression. (I also had to think   
   > twice about that format code.)   
   >   
   > BTW here is how my C transpiler translated it, so it /can/ be done   
   > without explicit temporaries:   
   >   
   >      mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x +   
   > y)),(i64)52,(i64)62),NULL);   
   >   
      
   Avoiding explicit temporaries is not a goal to aspire to - unless you   
   are trying to squeeze performance from a poorly optimising compiler.   
      
   >   
   >>   Of course you can write the same effect in C, in a simple function a   
   >> few lines long.   
   >   
   > Yes, everyone can invent their own solutions. (I've just taken that a   
   > few steps further with an entire language.)   
   >   
   >>   And that's the way it should be - obscure things should not take up   
   >> cognitive space that makes common things harder.   
   >   
   > But _BitInt(12) was also used as an example of saving a few lines of   
   > code or having to write a function or macro (there, to sign-extend the   
   > low-N bits of an integer value, when N is known at compile-time).   
   >   
      
   No, what was shown was how _BitInt(12) could let people write clearer C   
   code than C without _BitInt.  There was no comparison to other languages   
   or other features.   
      
   >   
   >>> But as a systems language, it is much more enticing than C.   
   >>   
   >> And that is presumably why it is so much more popular than C.   
   >   
   > If it was generally available then I think quite a few would prefer it.   
      
   Sure.  Keep telling yourself that.   
      
   > As it is I enjoy the benefits myself.   
   >   
      
   That I /do/ believe - and I genuinely think it is great that you enjoy it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)