From: bc@freeuk.com   
      
   On 09/10/2025 04:49, BGB wrote:   
   > On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >> On 08.10.2025 19:29, BGB wrote:   
      
   > Though, similar was often a problem in my other language design   
   > attempts: The most efficient way to do things was often also the C way.   
   >   
   >   
   >   
   > The only real exception I have found to this rule basically being in   
   > relation to some features I have borrowed from languages like GLSL and   
   > Verilog. But, some of this stuff isn't so much making the language   
   > "higher level" as much as "being easier to map to ISA features and   
   > optimize".   
   >   
   > Say:   
   >    vd[62:52]=vs[20:10];   
   > Being easier to optimize than, say:   
   >    vd=(vd&(~(2047ULL<<52)))|(((vs>>10)&2047ULL)<<52);   
      
   Using special bit-features makes it easier to generate decent code for a   
   simple compiler.   
      
   But gcc for example has no trouble optimising that masking/shifting version.   
      
   (It can do it in four x64 instructions, whereas I need nine working from   
   vd.[62..52] := vs.[20..10]. It could be improved though; I don't need to   
   extract the data to bits 10..0 first for example.)   
      
   The main advantage is that it is a LOT easier to write, read and   
   understand. The C would need macros to make it practical.   
      
      
   > Though, Verilog itself, not so much... Works well in an ASIC or FPGA,   
   > not so much on a CPU.   
   >   
   > Though, as can be noted:   
   >    Bit-ranges are required to be constant at compile time;   
   >    When used with normal integer types, both bounds are required.   
      
   I can handle some variable elements, but it gets rapidly complicated. At   
   some point it needs to use library functions to do the work.   
      
   >   
   > OTOH, GLSL offers nice and efficient ways to deal with SIMD.   
   > Well, and also having some types for bit-preserving casts.   
   > Or ability to specify endianess and alignment for individual struct   
   > members.   
   > ...   
   >   
   >   
   >>>   
   >>> Granted, a few of my own language design attempts ended up with a   
   >>> different mess:  [...]   
   >>   
   >> A sensibly defined language isn't something easily to create   
   >> or obtain! - Personally I'd have appreciated it more if more   
   >> designers of "own languages" have oriented their designs on   
   >> sensible existing and proven concepts. - There may be a   
   >> "market" for all these "own languages", I don't know, but I   
   >> also don't care much, given what I've seen or heard of yet.   
   >> (This isn't meant to be offensive, just to be clear, only   
   >> that I don't care much. As compiler writers don't care much   
   >> what I think.)   
   >>   
   >   
   > Yeah.   
   >   
   > They have either tended to not amount to much, or converged towards more   
   > conventional languages.   
   >   
   >   
   >   
   >>> [ attempt for a discussion on features of "own language"   
   >>>    snipped; not my business ]   
      
   (There are those who can devise and use their own languages, and those   
   who can't.)   
      
   > Some amount of my stuff recently has involved various niche stuff.   
   >    Interfacing with hardware;   
   >    Motor controls;   
   >    Implementing things like an OpenGL back-end or similar;   
   >    Being used for a Boot ROM and OS kernel;   
   >    Sometimes neural nets.   
      
   Some impressive stuff.   
      
      
   > Some features are useful in some contexts but not others:   
   > For example, "__int128" is very helpful when writing FPU-emulation code   
   > for Binary128 handling, but has a lot fewer use-cases much beyond this.   
   >   
   > Or, like:   
   >    exp=vala[126:112];  //extract exponent   
   >    fra=(_BitInt(128)) { 0x0001i16, vala[111:0]};  //extract fraction   
      
   I had i128/u128 types at one point (quite a nice implementation too; it   
   was only missing full 128-bit divide, I had only 128/64.)   
      
   But the only place they got used was implementing 128-bit support in the   
   self-hosted compiler and its library! So they were dropped.   
      
   > Unless maybe something can come along that is a better C than C...   
      
   There are lots of new products, mostly too ambitious, too big and too   
   complex. But C is already ensconced everywhere.   
      
   > Would likely simplify or eliminate some infrequently used features in C.   
   >   
   > Possibly:   
   >    Preprocessor, still exists, but its role is reduced.   
   >      Its role can be partly replaced by compiler metadata.   
   >    Trigraphs and digraphs: Gone;   
   >    K&R style declarations, also gone;   
   >    Parser should not depend on previous declarations;   
   >    Non trivial types and declarator syntax: Eliminate;   
   >    ...   
   >   
   > Possibly:   
   > Pointers and arrays can be specified on the type rather than declarator   
   > (so, more like C# here)   
   > ...   
   >   
   > But, as I see it, drastically changing the syntax (like in Go or Rust)   
   > is undesirable. Contrast, say, C# style syntax was more conservative.   
      
   Nobody cares about C syntax. Learning all its ins and outs seems be a   
   rite of passage.   
      
   The trouble is that C-style is so dominant, few people would know what a   
   decent syntax looks like. Or, more, likely, they associate a clean,   
   well-designed syntax with toy or scripting languages, and can't take it   
   seriously.   
      
   But if it looks as hairy as C++ then it must be the business!   
      
   > Though, the harder problem here isn't necessarily that of designing or   
   > implementing it, but more in how to make its use preferable to jus   
   > staying with C.   
   >   
   >   
   > One merit is if code can be copy-pasted, but if one has to change all   
   > instances of:   
   >    char *s0, *s1;   
   > To:   
   >    char* s0, s1;   
   >   
   > Well, this is likely to get old, unless it still uses, or allows C style   
   > declaration syntax in this case.   
      
   That one's been fixed (50 years late): you instead write:   
      
     typeof(char*) s0, s1;   
      
   But you will need an extension if it's not part of C23.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)