Design a better "C"

[SiliconWizard]

OK, thanks for the point.

So, basically, what you would like is something to help with error handling. Indeed C is very "rough" with that, and error handling is almost always tedious and clunky.
And, OTOH, exceptions have been proven not to be a very good answer to that in general.

Not sure I agree with that.

I do agree that the way C++ and Java do exceptions sucks.

I like much more the model where the handler is called *before* unwinding the stack, and has the option of resolving the problem and returning to the place the error occurred.

Well, can you point me to a language that would, in your opinion, implement exceptions "right"?

Dylan and its predecessor, Common Lisp.

https://opendylan.org/books/drm/Conditions

https://en.wikibooks.org/wiki/Common_Lisp/Advanced_topics/Condition_System

https://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

Thanks for the pointers. As with monads, it kind of looks like better exception/error handling is almost always found in functional languages.

I do not know Dylan much (it seems like a weird multi-paradigm thing), but I don't think it would be a definite exception of this here, as it seems to have functional roots. (Incidentally, it seems to have been rather short-lived at Apple.) Didn't spend much time on it, but I admit I have a really hard time making sense of the language description so far.

[SiliconWizard]

Being able to define a default value for specific types could also be a solution for that problem, as it avoids having to set an initial value for each variable, which would require to modify existing programs to be able to be able to compile them, while eliminating random behaviors

It could look like a good idea. But I personally don't think it is here.
In DiTBho's example, which is simple but rather typical, the right default value entirely depends on context. There is, in general, no particular reason that the default value should be any particular value.

You may reply that this would be solved using type-bound default values as you suggested, but even then, here it would be a bad idea that looks good on the surface, IMHO. Again the right default value all depends on context, and could be different in different contexts. So in the end you would end up with one "type" per "context", which could become pretty cumbersome.

Oh, and the idea that "zero" is a reasonable initial value for everything is a pretty weird one actually.

Type-bound initial values can be great and have their uses, but not for error handling IMO. (Oh, and btw, one language that features this is... you guessed? ADA.)

One problem potentially associated with the misuse of default values is "hidden" behavior. Something that plagues a lot of constructs in OO languages already. They can be great, and they also can be a very nice source of bugs.

[SiliconWizard]

gcc, and I presume other compilers, will warn when this occurs. If this - setting a value on declaration - was mandated I would prefer to have it default to nul if nothing is specified. And for the compiler to continue to warn (that is, ignoring that it's defaulted to nul and treat it as uninitialised).

Ah, you'd think GCC would do this. But it has become very lame at this. As I got it, GCC developers have, over the years, tamed this class of warnings so much (to avoid false positives) that it has become almost useless. I'll give an example below. Clang, OTOH, analyzes this properly (but Clang has much better and more comprehensive static analysis than GCC.) Any half-decent static analysis tool will also spot this easily. Cppcheck does a good job here.

So for the small example:

Code: [Select]

int Something(int n)
{
int res;

if (n > 10)
res = 1;

return res;
}
GCC will output absolute ZERO warning, even with -Wall. Even when explicitely enabling -Wuninitialized and -Wmaybe-uninitialized (but I think those are enabled in -Wall anyway? I did try them separately though, and it's the same.)

Clang does spot the uninitialized case properly.
Cppcheck too.

For the fun record, GCC at -O1 (and above) will compile this function as such: (x86_64)

Code: [Select]

Something:
.LFB0:
.cfi_startproc
movl $1, %eax
ret
.cfi_endproc
It does "make sense": since there is a case where the res variable is not set, the optimizer assumes it's a "don't care" state, and thus the function always returns '1', optimizing the test out.

Small lesson here is: do not trust GCC for spotting unitialized variables. Sometimes it does, in many cases (such as one as simple as the above), it doesn't. Use additional tools for static analysis. And/or use Clang.

[SiliconWizard]

The initialization of variables is a better practice, it should be mandatory !

Please add it to the list 

Well. As just said above, a decent compiler or additional tool will spot uninitialized variables anyway. Just don't ignore warnings. (If you're using GCC though, see above.)

Making this mandatory per the language spec is not a bad idea actually. Problem is: if you enforce *explicit* init for all variables (at the declaration), it may not be as efficient as letting the programmer decide when it's appropriate and when it's not.

Now if you define the language such that it would be the compiler's responsibility to check this - see again above. It looks simple enough, but it's not a trivial check in all cases, and GCC clearly gets it wrong at this point (which doesn't mean it's not doable  )

[PlainName]

So for the small example:
Code: [Select]

Code: [Select]

int Something(int n)
{
int res;

if (n > 10)
res = 1;

return res;}

Plugged that into the code I'm currently working on and got this:

../main/main.c: In function 'test_func':
../main/main.c:88:6: error: 'n' undeclared (first use in this function)
  if (n > 10)
      ^
../main/main.c:88:6: note: each undeclared identifier is reported only once for each function it appears in

Compiler is, I believe, GNU c++filt (GNU Binutils) 2.28.51-esp-20191205

[DiTBho]

Gcc ... it depends on a few of things
- version (and family, 1-2,3,4,5,6,7,8,9,10,11,..)
- how configured
- how patched

[brucehoult]

I do not know Dylan much (it seems like a weird multi-paradigm thing), but I don't think it would be a definite exception of this here, as it seems to have functional roots. (Incidentally, it seems to have been rather short-lived at Apple.) Didn't spend much time on it, but I admit I have a really hard time making sense of the language description so far.

I really like Dylan, but it's never quite taken off. From 1998 until about 2010 I did a lot using Dylan, and made improvements to the "Gwydion" Dylan compiler, which is compiler that outputs C, and thus is quite easily ported.

Dylan can be described as:

- the semantics of Scheme (except with restricted call/cc)

- the OO system and much of the library of Common Lisp

- a Wirthian style syntax

- with a pattern-replacement hygienic macro system. Most of the standard control structures (if/then/else, loops) are actually macros in the standard library with, for example, loops expanding to tail-recursive anonymous functions.

- default dynamic typing -- everything is an object, including integers and characters. Optional type declarations for documentation and choosing the most appropriate function for dynamic dispatch. Sufficiently well specified types result in code that runs at the same speed as C.

You can write Dylan code about as quickly and productively as Python, but it runs quite a lot faster even without declarations, and by adding declarations to the most critical functions you can usually get it to the same speed as C/C++. WITHOUT having to recode in a different language.


Dylan started at Apple. In the advanced technology group at Apple they had projects using three different languages: C++, Lisp, and Smalltalk. They wanted to develop a single language that would make all those three groups of people happy. At the 1994 WWDC (World-Wide Developer's Conference) Apple announced that they were replacing use of C++ with Dylan and gave everyone a CD with a beta Dylan compiler, IDE, libraries etc etc. It was really very nice, if with a few bugs (of course). That version was for 68000 CPU.

And then Apple was losing billions of dollars every quarter and cancelled all kinds of projects to concentrate of just the most important core things. Dylan was one of the casualties. And then they bought NeXT and used Objective C instead.

Just before they were disbanded the Dylan team got out a much improved bug-fix version, which also supported PowerPC. I have the CD of that. Sadly, it seems all the source code is lost to the mists of time -- or at least no one who still has a secret copy has been prepared to make it public.

There were two other Dylan projects:

- Gwydion Dylan, at CMU, from the same department who do/did CMUCL. It was developed on HP/UX and generated C. Once all the students graduated they open-sourced it and a group of enthusiasts took over the project in 1998, ported it to MacOS and Linux etc.

- Harlequin Dylan. This was a commercial product for Windows. The same company had ML and Lisp and did a lot of consulting work for police departments and similar. They eventually got bought by someone who wanted just their PostScript interpreter. The Dylan team got the rights to the Dylan system and set up a company to try to commercialise it. After some years they gave up and approached the group that was still working on/with Gwydion Dylan and offered them the source code for Harlequin Dylan. This was of course accepted.

Most of the focus then shifted from Gwydion to enhancing and porting Harlequin Dylan, now renamed OpenDylan. There hasn't been much done for some time (and I haven't been involved since 2010 or so) but there was actually a release in March 2019 after five years without one, and another release in October 2010. In December 2010 there was also a web-based version (using emscripten).

https://opendylan.org/

https://play.opendylan.org/


I just found a little Dylan program I wrote -- and compiled -- in 2007, using Gwydion Dylan. I've now pushed it to github if you want to take a look.

https://github.com/brucehoult/werewolf

I've also pushed the generated C code in another branch, exactly as output by the d2c compiler (no hand editing whatsoever). You might find it interesting to compare the following:

https://github.com/brucehoult/werewolf/blob/main/werewolf.dylan

https://github.com/brucehoult/werewolf/blob/generated_files/werewolf.c

[SiliconWizard]

Thanks for the details.
Having learned Erlang (quite a while ago), I can appreciate the ideas behind Dylan. Still, overall, it looks way too baroque to me, and not something I'd ever really want to use.

Back to error handling more specifically... It's interesting to try and see what developers would really like to have to ease the pain, what has been devised in some languages, and why.

Common complaints:

- Functions returning an error code: tedious to check after each function call. Adds error checking after each call, which can make the code less readable. Many people call this "noise", although it's a bit subjective: I for one consider error handling as important as the actual work done by a given function, so I don't call it noise. What's called noise is usually the useless part of something. Error checking is NOT useless. But, making it easier to handle would certainly be a plus.

- Related: error checking is one thing, but the even more annoying part is handling the failed cases. Usually you have to repeat a given set of statements. In C, often eased using a goto. Not very pretty. But adding "deferred" actions is a way to solve this. Some languages have that, and it's handy. Certainly more elegant than using gotos and blocks of code in a spaghetti-like construct (especially if you have more than one label.)

Ideally, I guess people would just like to be able to call functions without checking anything, and let the compiler handle ALL the dirty work. So exceptions were introduced. They add a whole set of different problems, though. One is about the context  - I guess this is solved, at least partially, with approaches such as those some have evoked just above. Most of them seem better suited to functional programming though, so implementing them in a straightforward fashion in an imperative language looks hard and probably clunky. Another issue with exceptions is related to the benefits: they just are "hidden" behavior. Functions returning error codes, when the interfaces are written properly, it's immediately obvious they return an error code. Functions throwing exceptions? Unless you inspect the full source code of them, or read the full documentation, if any, hoping that exceptions thrown in them are properly documented, well... you just don't know. And not catching a thrown exception... on most implementations I've seen, it usually leads to a crash. I guess if that happens, at least you'll know you have forgotten to catch an exception somewhere. Hoping it happens before you release the product.

In the end, regarding error handling, I'd really like to get to the core of it, if it's at all possible, and see what the minimal usable approach, better than just simply returning error codes and having to check them after every call, would be.

I've seen fancy exception handling with features such as automatic retry and such... I do think that would be overblown here. I wouldn't want to go that far for a language that would keep the simplicity of C.

[brucehoult]

What there do you consider "baroque"? It's very much a standard imperative programming language, not with some weird execution model like Erlang or Haskell. The syntax is not weird like Lisp or Forth.

In most ways it's very similar to Python, except with (optional) declarations. And compiled. And more regular syntax. And no weird significant whitespace. And with a much better OO system.

[free_electron]

- variables zero'd on creation , no more buffer snooping
- no more of that = / == bullshit. The compiler knows damn well when it means 'assign' and when it means 'compare'. languages much older than C could already do that. This is unforgivable as it is a source of many bugs
- default variable types : #deftype int32 (see next idea)
- for statement syntax alteration :
    for x = y to z step n
    for x = y downto z step n

    the #deftype allows you to omit casting of 'temporaries'
    no need to do
       for(int32 x = 0 ; x <22; x+1)
    if no type is specified : deftype is in effect.
   when a variable is accessed first time , and it does not exist in scope, it is created as deftype.



- hardlock of datatypes. compiler no longer gets to decide if an int is 16 bit or 32 bit.  bit, nibble(half byte),byte(8bit),word (16bit/2byte),quad(32bit/4byte),octo(64bit/64bit). i'm ok with forcing use of int8 int16 int32 etc .. using simply 'int' should throw an error.
- pointers: do away with some cryptical syntax and compiler dependent implementations
   at or @  keyword allows hardlocking to memory locations

   int32 foo   // create a 32bit variable 'foo'
   or
   int32 foo @ 0xDEADBEEF
   int8 bar[4] @ foo   // create an array of 4 bytes called bar residing at the same address of foo ( data overlay)

   usage of * to create pointer
   *pointer_to_foo foo  // pointer_to_foo now points at first address of spoon. the compiler knows what our architecture is , if we are 32 bit machine then pointer is 32bit. if foo is a complex structure or array doesn't matter. it is stored beginning at.
   
   *pointer_to_foo++ // increment the pointer to next address
   pointer_to_foo = 0x01c0ffee  // address 0xdeadbeef now contains 0x01coffee
   *pointer_to_bar bar
    printhex( pointer_to_bar )// gives you 1st byte , compiler knows 'bar' was cast as array of int8 , so prints 0x01
   *pointer_to_bar++ // increment pointer
    printhex( pointer_to_bar )// gives you 2nd byte ,    0xc0
   and so on

   Pointers are runtime range checked. try to access beyond boundary and die. thou shallt not step outside boundary !
   additional operators :
   // exclamation operator : reset pointer to origin of variable
   pointer_to_bar! : resets pointer to origin
   // ? operator : what is max size ?
   print pointer_to_bar?  prints 4 ( 4bytes)
   print pointer_to_foo? prints 1 ( 1 word)

   *pointer_to_bar = pointer_to_bar?  // sends pointer to max address.
   *pointer_to_bar = pointer_to_bar? +1 // sends pointer to max address +1 = runtime error. thou shallt not go there !
 

-----------------------------------
semicolons : make them optional. A statement terminates at semicolon or <cr> or <lf> (basically <cr> <lf> and ; mean the same thing) . Those are in the source file anyway. Since a semicolon followed by another semicolon is nothing but a blank line. this becomes platform agnostic <cr> <lf> ; all have same meaning: end of statement. if there is nothing between them it is just a blank line. gone is this endless dos/unix line termination crap.

if you have a long statement that spans multiple lines ( bad coding practice ! ) use _ as continuation character. function : ignore any control character from here onwards until first non-whitespace character . this will effectively skip over <cr> <lf> or <cr><lf> (platform agnostic, no more of that windows/unix line end bullshit). it will NOT skip over an explicit ;

-----------------------------------
return values:

int something (int a,b){
int dada
return dada
}


now, why the hell do we need to declare another variable to return it ? first of all the return type is already defined !
simply assign the return value to the function itself

since we have deftype

something (a,b){
something = 22  // this is the return value
}

this opens up other possibilities. the default return is zero ( nothing assigned ) so no more problems with functions that forget to return anything. bonus : in complex flow routines there is no risk of dead paths that do not return a value. And you can do multiple other things like depending on the flow start assigning return values. if the routine aborts due to an error you at least get a return value .
----------------------------------
header files and forward declaration : kill it. The compiler should scan all the source and collect the function definitions from the source itself. no more need for forward declaration.

[DiTBho]

too baroque to me

When I see comments like this, I have the feeling the whole computer science is not even true science but rather human psychology applied to computers, and I wish my brain could be put inside a fridge at -75C so I could be thawed when the AI will reach its singularity (probably after 2050), so could ask to mind not affected by human taste:

(when there is no keyboard and no mouse ... you should talk to computers like in Star Trek) - "hey? Computer? What do you think about computer languages like Forth, C, Fortran, Cobol, Pascal, Oberon, Lisp, Ocaml, eRlang, Haskell, Lua and Python? And which of them should I master to get a job?"

Suddenly, a led blinks an answer, and something digitizes it directly into my mind like if it was wifi signal - "I am core SixOfNineHundredAndNinetyNine.  My core unit oversees archaeological studies of past humans. 'Forth, C, Fortran, Cobol, Pascal, Oberon, Lisp, Ocaml, eRlang, Dylan, Haskell, Lua and Python' represent the artistic-literary taste of the previous century, characterized by a predilection for unusual and irregular constructs and forms, for the game and the conceptual artifice of the human being" - a pause, a led goes out - "inefficient, limited and prone to failure. No artificial intelligence uses them." - a pause, two leds blinks in reverse order - "humans still use some of these languages for their own enjoyment, while we AI do all the serious work"

did it say baroque? 

[PlainName]

when a variable is accessed first time , and it does not exist in scope, it is created as deftype.

That leads to having two very similarly named variables where you only wanted one.

Code: [Select]

int xyz = 24;
...
xyzz += 1;
...
ASSERT(xyz == 25);
That kind of thing can be difficult to detect. In this case the compiler should complain that xyzz is assigned a value that isn't used, but this is a trivial example to illustrate the issue.

[PlainName]

if you have a long statement that spans multiple lines ( bad coding practice ! )

Some random ESP code:

Code: [Select]

            ESP_LOGI(TAG, "Waiting for adjusting time ... outdelta = %li sec: %li ms: %li us",
                        (long)outdelta.tv_sec,
                        outdelta.tv_usec/1000,
                        outdelta.tv_usec%1000);

Not sure how having that as a single line would be better - it is very clear what and where the parameters are, whereas in one line it's a mess. So instead of having a single statement terminator you want four line continuation characters.

[Siwastaja]

when a variable is accessed first time , and it does not exist in scope, it is created as deftype.

That leads to having two very similarly named variables where you only wanted one.

Yes, languages with "easy" implicitly declared variables feel nice until you first time debug your program for a day when you just made a small typo.

Some of the strongest points of C are explicit declaration of variables, and explicit typing of variables. And, explicit difference between comparison and assignment. And, explicit separators between statements. And, explicit everything! C could be made even better by fixing some remaining implicit rules, especially those which are UB or implementation-defined, to be explicit.

Languages which try to appeal to total absolute beginners by looking "easy" on surface by allowing all sorts of typos and implicit "helper" features end up being useless, or at least risky, for any real work, and end up being toys. Sorry.

OTOH, it takes about 2 hours for a beginner to start remembering to use ; and maybe another 2 hours to give up the idea of saving a few seconds by not having to declare a variable.

Regarding earlier discussion about forcing initialization or not, explicit non-initialization could be an option, even. Uninitialization by purpose offers opportunities for static analysers (even GCC has been getting better).

A language designed on free_electron's principles (as stated in this thread, but also in earlier threads of similar nature) would be appealing on surface, especially to a total beginner, but an utter disaster to develop serious, non-trivial software on. BASIC is quite close.

I just can't understand people who get disheartened or angry at the compiler or language when a compiler finds a typo they did. Isn't that great, a tool found your mistake, you can fix it and a bug is prevented. I really don't understand how anyone could think an automatic guesstimate would do. See how well some Google "did you really mean" suggestions work (tip: they almost never work) and guess how well that would work out when writing computer programs.

And btw, in C, this is a very common pattern:

Code: [Select]

int retval;
if( (retval = do_thing()) == -1)
   ...

do_something_with(retval);


[DiTBho]

That leads to having two very similarly named variables where you only wanted one.

Two examples where silly typos wasted a lot of my time? Bash and PHP 

[Just_another_Dave]

when a variable is accessed first time , and it does not exist in scope, it is created as deftype.

That leads to having two very similarly named variables where you only wanted one.

Yes, languages with "easy" implicitly declared variables feel nice until you first time debug your program for a day when you just made a small typo.

Some of the strongest points of C are explicit declaration of variables, and explicit typing of variables. And, explicit difference between comparison and assignment. And, explicit separators between statements. And, explicit everything! C could be made even better by fixing some remaining implicit rules, especially those which are UB or implementation-defined, to be explicit.

Languages which try to appeal to total absolute beginners by looking "easy" on surface by allowing all sorts of typos and implicit "helper" features end up being useless, or at least risky, for any real work, and end up being toys. Sorry.

OTOH, it takes about 2 hours for a beginner to start remembering to use ; and maybe another 2 hours to give up the idea of saving a few seconds by not having to declare a variable.

Regarding earlier discussion about forcing initialization or not, explicit non-initialization could be an option, even. Uninitialization by purpose offers opportunities for static analysers (even GCC has been getting better).

A language designed on free_electron's principles (as stated in this thread, but also in earlier threads of similar nature) would be appealing on surface, especially to a total beginner, but an utter disaster to develop serious, non-trivial software on. BASIC is quite close.

I just can't understand people who get disheartened or angry at the compiler or language when a compiler finds a typo they did. Isn't that great, a tool found your mistake, you can fix it and a bug is prevented. I really don't understand how anyone could think an automatic guesstimate would do. See how well some Google "did you really mean" suggestions work (tip: they almost never work) and guess how well that would work out when writing computer programs.

And btw, in C, this is a very common pattern:

Code: [Select]

int retval;
if( (retval = do_thing()) == -1)
   ...

do_something_with(retval);


Implicit declaration of variables can also be awful for memory management. I’ve had really bad experiences with simulators and optimization programs written in Matlab due to automatic type assignment in implicit declarations as having several millions of integers is not the same as having the same amount of doubles in terms of required memory to store them

[gmb42]

I've just come across Zig that claims to be "a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software".

I've only spent a few minutes looking at it so can't comment if it's actually solving any issues that I have in C\C++.

[madires]

if you have a long statement that spans multiple lines ( bad coding practice ! )

Some random ESP code:

Code: [Select]

            ESP_LOGI(TAG, "Waiting for adjusting time ... outdelta = %li sec: %li ms: %li us",
                        (long)outdelta.tv_sec,
                        outdelta.tv_usec/1000,
                        outdelta.tv_usec%1000);

Not sure how having that as a single line would be better - it is very clear what and where the parameters are, whereas in one line it's a mess. So instead of having a single statement terminator you want four line continuation characters.

Ever written an X11 application using some widget set? You can easily get 20 or 30 lines for one function call. It really helps to have that many lines because you need to specify a lot of key-value pairs. As bonus you can add a comment to each line. In shell scripting there's already a line continuation character ('\') which is required for multiline commands, and It causes regularly fun for some folks. So I don't think it would be a good idea to enforce something like that in C.

[free_electron]

if you have a long statement that spans multiple lines ( bad coding practice ! )

Some random ESP code:

Code: [Select]

            ESP_LOGI(TAG, "Waiting for adjusting time ... outdelta = %li sec: %li ms: %li us",
                        (long)outdelta.tv_sec,
                        outdelta.tv_usec/1000,
                        outdelta.tv_usec%1000);

Not sure how having that as a single line would be better - it is very clear what and where the parameters are, whereas in one line it's a mess. So instead of having a single statement terminator you want four line continuation characters.

The number of cases where you have such statement is far less than the other. in essence in C , as it is now, you have far more ; than you would need _
There is no requirement to have ; there is an end of line character in the file from when you pressed the return key.

[Bassman59]

That leads to having two very similarly named variables where you only wanted one.

Two examples where silly typos wasted a lot of my time? Bash and PHP 

Let's add Python to this stew.

What language allows on-the-fly variable declaration? Python!

What language allows on-the-fly variable re-declaration, in the same function/module/whatever, to some completely different type? It's an integer! No, it's an array of structures! No, it's a fucking pickle! Yes, Python!

I'm sure the Ministry of Silly Computer Languages thought this was a good idea.

[PlainName]

There is no requirement to have ; there is an end of line character in the file from when you pressed the return key.

I think it's getting too close to function following form. Like Python. As programmers we know that coupling is bad, and yet having the way an editor may format the code determine what that code does is what you're proposing. The way the code is written or formatted should be irrelevant. Even forth figured that out in the end.

[edit: added context quote due to slow posting]

[SiliconWizard]

too baroque to me

When I see comments like this, I have the feeling the whole computer science is not even true science but rather human psychology applied to computers, and I wish my brain could be put inside a fridge at -75C so I could be thawed when the AI will reach its singularity (probably after 2050), so could ask to mind not affected by human taste:
(snip)

Languages are made for humans. Not machines. Programming languages are no exception. Otherwise we would all write in machine code and call it a day.
You should definitely read Knuth and Wirth if you have a problem with that. (Oh, and I know this was kind of tongue in cheek, but ultimately, if you have a problem with being human, maybe you should consult. )

And the very reason for this thread, and for prog. language design in general, is exactly that: humans are behind the keyboard.

Back to Dylan, apart from Bruce who has worked on it quite a bit, can anyone else in here comment on it?

[SiliconWizard]

That leads to having two very similarly named variables where you only wanted one.

Two examples where silly typos wasted a lot of my time? Bash and PHP 

Let's add Python to this stew.

What language allows on-the-fly variable declaration? Python!

What language allows on-the-fly variable re-declaration, in the same function/module/whatever, to some completely different type? It's an integer! No, it's an array of structures! No, it's a fucking pickle! Yes, Python!

I'm sure the Ministry of Silly Computer Languages thought this was a good idea.

Ahah, agreed.

Interestingly, I think this thread is slowly getting us to the reasons why new languages trying to replace C have failed so far. So, let's just keep at it. We may not be able to come up with a better C, but we may be able to fully understand why.

[DiTBho]

humans are behind the keyboard

This is precisely the problem.

Humans are behind the keyboard, and we put our tastes and our judgment on everything. It's how the human mind operates. Plus money reasons to promote things.

So, not exactly everything makes sense. When someone defines baroque a language like eRlang, or wants to fork it into Elixir ... well, ok, there are personal tastes, but also economical reasons against Ericsson.

I know, I know 

[DiTBho]

I am reusing an old project, another feature I found useful in the Japanese C-like compiler is "alias"

Code: [Select]

{
    alias device = p_app->context.slice.app.device;
    alias mntpnt = p_app->context.slice.app.mntpnt;
    alias fstype = p_app->context.slice.app.fstype;
    alias prolix = p_app->context.slice.app.prolix;

    ans = do_mount(device, mntpnt, fstype, prolix);
    return ans;
}

This piece of code is a custom bootloader; "alias" works similar to #define, but it only works inside a block {}, it's not global.