The Imperium programming language - IPL

[Sherlock Holmes]

Language v1.0 reserved words = if then else call end

Language v1.1 reserved words = if then else call end goto return

Language v2.0 reserved words = if then else call end goto return interrupt coroutine allocate

Language v3.4 reserved words = if then else call end goto return interrupt coroutine allocate lock trap retry

Does this make it clearer? We simply do not know what new features/keywords might get added in each future version of a language. Therefore if we add to the list of reserved words with each version we will eventually break older code somewhere, a v1.0 source file in part of a library, might have used "lock" as a procedure or function name, but refuses to compile under v3.4

There is nothing to stop us though from issuing style notices, or optionally telling a compiler (via some option) to act as if keywords are reserved and report errors, that's fine, that's a teams conscious choice though not an imposition by the language.

Being able to say "we might add zero or more new language keywords in each future version but guarantee that your existing source code will always compile, your code is guaranteed to compile under every future language version".

Names also must be explicitly declared, so unless one declares "if' and "then" and "else" there cannot be accidental confusion, the examples I've shown are test cases, proof that the grammar definition is sound, contrived examples used to test the grammar and parser, nothing more.

Reserved words are "training wheels", handcuffs to the language designers, anyone can write confusing looking code in any language, but that's their call, if they want to do it then that's their choice, C has plenty of reserved words but still let's us write insane looking code, keyword reservation is old fashioned thinking, time to move on.

Read this https://doc.rust-lang.org/reference/keywords.html

[tggzzz]

Why not limit the keywords to being 6 pseudo-variables and nothing else? That allows you to have whatever control structures are suited to your requirements.

That's proven to be successful in embedded instruments manufactured by HP and Tektronix, e.g. protocol analysers and oscilloscopes and maybe more. I believe it to be significant that they were produced by hardware engineers (not software engineers) that only cared about how a language behaved and could achieve easily, and didn't care about the language itself.

The 6 words were/are: true, false, nil, self, super, thisContext.

[Sherlock Holmes]

Why not limit the keywords to being 6 pseudo-variables and nothing else? That allows you to have whatever control structures are suited to your requirements.

That's proven to be successful in embedded instruments manufactured by HP and Tektronix, e.g. protocol analysers and oscilloscopes and maybe more. I believe it to be significant that they were produced by hardware engineers (not software engineers) that only cared about how a language behaved and could achieve easily, and didn't care about the language itself.

The 6 words were/are: true, false, nil, self, super, thisContext.

Smalltalk is listed here: https://stackoverflow.com/questions/4980766/reserved-keywords-count-by-programming-language

They left out PL/I and Fortran and a few others that are all 0.

[Siwastaja]

Not only cycle accurate, but extremely easy to understand and maintain, not like the *x++ = **t-- C horror ?

Think about it - in C, ***************************x is a valid expression, C bad.

"if if then if else then if if if if if then then if if if else then" is much better!

[tggzzz]

Not only cycle accurate, but extremely easy to understand and maintain, not like the *x++ = **t-- C horror ?

Think about it - in C, ***************************x is a valid expression, C bad.

"if if then if else then if if if if if then then if if if else then" is much better!

No it isn't, since "all problems in computing can be solved by an extra level of indirection"

Similarly "all problems in signal processing can be solved by integrating for longer".

[Sherlock Holmes]

Not only cycle accurate, but extremely easy to understand and maintain, not like the *x++ = **t-- C horror ?

Think about it - in C, ***************************x is a valid expression, C bad.

"if if then if else then if if if if if then then if if if else then" is much better!

Except of course that the latter is syntactically wrong, illegal, gibberish; whereas the former is valid, legal C gibberish!

[Siwastaja]

Think about it - in C, ***************************x is a valid expression, C bad.

"if if then if else then if if if if if then then if if if else then" is much better!

Except of course that the latter is syntactically wrong, illegal, gibberish; whereas the former is valid, legal C gibberish!

What, your language uses whitespace as a syntactic separator? Why would you do that, isn't that limiting? What if the user wants to have spaces in the variable names, or what if you later find out you want keywords with spaces? I just wanted to have a variable named "if then if else then if if if if if then then if if if else" and you call it gibberish. Or wait, no, actually I want it with line feeds in variable names and all, how about:

Code: [Select]

   if if else then
      else if else then else
          then then =
      if then then


Clearly the language isn't powerful enough, yet! But I'm sure you'll get there, and the cycle-accurate PIC developers will thank you.

[Sherlock Holmes]

Think about it - in C, ***************************x is a valid expression, C bad.

"if if then if else then if if if if if then then if if if else then" is much better!

Except of course that the latter is syntactically wrong, illegal, gibberish; whereas the former is valid, legal C gibberish!

What, your language uses whitespace as a syntactic separator? Why would you do that, isn't that limiting? What if the user wants to have spaces in the variable names, or what if you later find out you want keywords with spaces? I just wanted to have a variable named "if then if else then if if if if if then then if if if else" and you call it gibberish. Or wait, no, actually I want it with line feeds in variable names and all, how about:

Code: [Select]

   if if else then
      else if else then else
          then then =
      if then then


Clearly the language isn't powerful enough, yet! But I'm sure you'll get there.

Whereas you won't, if there's no grammar (formal syntax rules that can generate a parse tree) then it's not a language, its gibberish.

If you can define a grammar for your "language" I'll listen, until then...

[DiTBho]

Incompetents do nothing but wasting people's time and resources.

[Sherlock Holmes]

Language v1.0 reserved words = if then else call end

Language v1.1 reserved words = if then else call end goto return

Language v2.0 reserved words = if then else call end goto return interrupt coroutine allocate

Language v3.4 reserved words = if then else call end goto return interrupt coroutine allocate lock trap retry

Does this make it clearer? We simply do not know what new features/keywords might get added in each future version of a language. Therefore if we add to the list of reserved words with each version we will eventually break older code somewhere, a v1.0 source file in part of a library, might have used "lock" as a procedure or function name, but refuses to compile under v3.4

There is nothing to stop us though from issuing style notices, or optionally telling a compiler (via some option) to act as if keywords are reserved and report errors, that's fine, that's a teams conscious choice though not an imposition by the language.

Being able to say "we might add zero or more new language keywords in each future version but guarantee that your existing source code will always compile, your code is guaranteed to compile under every future language version".

Names also must be explicitly declared, so unless one declares "if' and "then" and "else" there cannot be accidental confusion, the examples I've shown are test cases, proof that the grammar definition is sound, contrived examples used to test the grammar and parser, nothing more.

Reserved words are "training wheels", handcuffs to the language designers, anyone can write confusing looking code in any language, but that's their call, if they want to do it then that's their choice, C has plenty of reserved words but still let's us write insane looking code, keyword reservation is old fashioned thinking, time to move on.

Read this https://doc.rust-lang.org/reference/keywords.html

Yes, that does make it clearer.  I (also, if you do as well), also have much respect for Rusts, concerns and attempts/features, which attempts to take responsibility, for not only current source code, but older source code as well.  I.e. it hopes to allow current (or older) source, code to remain  compilable/compatible with new standards.  E.g. By allowing specific command version numbering syntax, to help with that process.

I think as already mentioned in this thread.  There is a fundamental problem, with new programming languages, in general.  They tend to have a fair amount of changes, in the early releases, as there is potentially much refining, polishing and fine honing/tuning of the language.  In the light of experience, and as more users, join the increasing family of people, using the new language.

I'm glad, you, early on are taking much thought and consideration, into this (apparently) important issue, with programming language design.

But there are other solutions.  Another would be to start off with a completed, reserved word list, which is set in stone.  Call it the 'hard' reserved word list.

For future releases of the language, any additions to the reserved list, can only be added to a 'soft' reserved word list.  The 'soft' version, unlike the 'hard' version, CAN BE over-ridden by the users of the compiler.  Unlike the original 'hard' reserved word list.

That way, you could get to eat your cake, and keep it.

Also, any obsolete 'hard' reserved words, could, instead of deleting them, be moved, at least for a long while, into  the 'soft' reserved word list.

'soft' reserved words, could still produce a compiler warning message.  With options to either treat it as an error, or ignore it completely.  As compiler flag options.  Then users could choose, how they want to treat the various reserved word lists.

Some languages, seem to use additional syntax, to allow many (rare) reserved words (or hidden variables/features, link/compiler information etc).  But because of the syntax, they will tend to never clash with programming source code.

E.g. using '_errorNumber' and '_errorDesription' to find out the compilers last run time, error codes/messages.  As they are less likely to be chosen names in the compiler, compared to e.g. 'error'.
E.g. Prefixing new words with an underscore or two. '_start' or '__start', or ending with a '!'. Etc.

Some languages (Python, I'm looking at you), change so much between, e.g. 2.0 and 3.0, that to all intents and purposes, it is a new and/or completely different (and relatively incompatible) language.  So, this does seem to be a REAL issue.

Even some/many frameworks/libraries and things, can change so much, between major revision numbers.  That there is massive incompatibilities, between them.  With various negative consequences, such as programmers who were familiar with (e.g. GTK2, compared to GTK3, and then GTK4), having later version(s), being significantly different, so they effectively have to re-learn it and rewrite/modify lots of code, in some cases.
It can annoy/alienate some/many people, so that they end up turning their backs on such systems.

You raise some good points, I'll think about what you suggest here. It would certainly be easy to make this stuff optional, or directive driven. For example we could envisage options like -reserved none, -reserved min, -reserved max or -reserved (if, then, else) that kind of thing.

Here 'min' means your 'soft' concept, reserves a core set of very common keywords but no more. The 'max' option on the other hand would reserve every keyword in the current version of the language, some people might value that, happy to see any clashes yet be able to still compile and change their code at a later time.

This is close to trivial to do, so long as the grammar itself imposes no restrictions, the compiler itself would do this. It must walk the parse tree anyway and can easily see if an identifier is also a keyword and then either do nothing or complain depending on the compile options.

I don't think some people here grasp the fact that if the grammar itself has reserved words then you're locked in fundamentally, reserving words outside of the grammar during one of the compilation phases is much much better.

So I do very much like your idea.

[Sherlock Holmes]

There are potentially a lot of keywords too, so reserving all is a big burden cognitively on the programmer. This is just some of the keywords I'm expecting to have:

if then else while end proc procedure func function, dcl declare, bin binary dec decimal fixed float complex cplx def define call return coroutine cofunction yield to by when static auto automatic based defined ptr pointer allocate bit string byte free goto go to

You get the idea, the fact is this set can grow over time (new language features, attributes, data types etc) without any worry or concern we might break some user's code base, sure some users might want to reserve some or all (current) keywords, but that's their call and they should be given that option.

Imagine you were calculating the yield of some process:

Code: [Select]


yield = ((total - defects) / total) * 100;


Then one day you upgrade to v3.4 of newlang only to find your code no longer compiles because newlang now supports iterators and 'yield' can no longer be used that way! Right away we must change code, run unit test, create commits, review code and so on, a total waste of people's valuable time all imposed by a language because the designers didn't think about backward compatibility.

[Sherlock Holmes]

Then one day you upgrade to v3.4 of newlang only to find your code no longer compiles because newlang now supports iterators and 'yield' can no longer be used that way! Right away we must change code, run unit test, create commits, review code and so on, a total waste of people's valuable time all imposed by a language because the designers didn't think about backward compatibility.

It is not just that.  When such changes occur, significantly in the future.  The original programmers, may be unavailable (busy on other projects), or have left the company.  Even if available, it might be many years ago, when they wrote that code, so they have totally forgotten about it.
So, for them (or others), to now go back, and rework the source code.  Can be a rather time-consuming, problematic (further new bugs might be introduced, because they no longer understand the code), and an expensive loss of (valuable/limited) resources, that could be better spent, doing other useful things.

It might even be someone, trying to recompile the software, and sort out any dependencies, just so they can use it, some time in the future.  So if the (then) current V3.4, no longer compiles, without many fatal errors, using the existing source code base (which could be open source or commercial).  That will put a real damper, on the activities, within the new language.

Some (very successful and popular) programming languages, have such huge existing software bases, in source format.  That making future changes to the language, without breaking any existing functionality.  Can be a real-minefield.

Taking CPU instruction sets, as an analogy.  On the one hand, the X86 / X86-64 instruction sets, have amazing compatibility, even going back around 40 years, to the original 8086/88 CPUs.  But some people think, that it also causes big baggage (like) problems.  Whereas alternative architectures, such as Arm, tend to be rewritten from scratch, only going back one or two instruction sets, as regards compatibility.  But that potentially allows the instruction set to move on from the old days, and soak up, any modern CPU performance improvements, with minimal handicapping, from old, somewhat obsolete instruction sets, of the distant past.

E.g. How many people, really run native 8088 programs, on their 192 core (dual socket 2 x 96 core), AMD Epic processors?
I have heard some of the backward compatibility, may be no longer available, but I'm not sure.  Removing it has been discussed, but I'm not sure if it happened or not.
Windows, seems to happily drop support, for even rather modern/recent processors.  But that could be, because they get paid license fees, mainly when new PCs are purchased, so it is in their interests, to obsolete CPUs, even if they are rather recent ones.

In other words.  It is annoying when a programming language, introduces, show breaking changes, between say versions 2.0 and 3.0 .  But, that might (or might not), be worth it, from a longer time scale point of view.

E.g. Despite Python, sometimes dramatically changing, between major release number versions.  It does seem to still be very popular.  So I wouldn't like to say, one method is best.  It is a tricky situation to handle.
As they say, you can't make a omelette without breaking eggs.  Maybe such dramatic changes, is ok, if done responsibly, and only very rarely.  Such as once every 7 or 8 years.

If you DON'T allow show stopping changes, ever.  Eventually the thing (a programming language in this case), can eventually become stale and fixed.  Unable to move forward, with any/much momentum.  Ultimately, risking the language becoming obsolete (i.e. people stop using it), as time goes on.

If you are still primarily aiming this to be an MCU language.  There is a tendency for such projects, to have relatively short development time-scales (but, they COULD be very long, it depends).  With whatever language version, they started out with, on that particular MCU, remaining, throughout the project life-time.
Because if you have MCU (embedded) software, which works well and is considered bug free.  Made with version 1.24 of the compiler, nine years ago.
Experience tends to find, that if you update the compiler to the latest version 9.79, on a much later version of windows.  There is a tendency, for various bugs (that didn't exist previously), to suddenly appear, mismatches within the new (updated) libraries and even entire functionality, that is no longer present in the latest libraries that come from the manufacturer.
The latest compiler, may not even work, with your MCU, from many years ago.

If it ain't broke, don't mess with it.

With FPGAs, and older specific FPGAs, typically.  You can't even use, older FPGAs, on the latest FPGA software packages, as support was dropped for those older FPGAs, many years/versions ago.

You started off this thread with mention of PIC MCUs.  Which tend to lose support for the older PIC models, on the latest programmer-devices/compilers and libraries.  So, total backward compatibility, may not be necessary or even a good idea.  I suppose care/caution is needed.

Also remember the K.I.S.S. (Keep It Simple Silly/stupid), principal.  Making the compiler too overly complicated, with way too much functionality.  May mean that, it can never be completed, given its available resources (such as programming team size/time, for creating the compiler).  Sometimes, you have to harshly remove extra functionality, to make things practicable.

I did start the thread with an emphasis on MCU applications, that's true. Perhaps I should explain/clarify what that means. To me, it means a compiled language that includes features that although having general world use, are particularly helpful to the hardware programmer. In other words a language that can be attractive and linguistically contends with C and comparable languages used today.

For example explicit support for a bit data type, operators for arith-shift, logic-shift, several ways of overlaying types in memory, offset as well as traditional pointers and so on.

A little bit about me too, might also help understand my position here, I apologize for the length and the apparent self indulgence. I was an electronics hobbyist as a kid, when I lived in Liverpool UK. I was about 14 or so when a mate introduced me to transistors, radio and stuff. I quickly became engrossed and he and I did several projects together in the mid/late 1970s.

We managed to get stuff published in Everyday Electronics too, a bit of cash but a fun experience for two teenagers. I soon became absorbed by microprocessors after they became huge in magazines like Practical Wireless and ETI, I bought a basic 6502 kit from Acorn and interfaced that to motors and all sorts.

By the age of like 18/19 I got into a specialist electronics college (my mate got a place at Riversdale college in Liverpool and studied marine radio and radar and ended up doing defense work overseas for a few years) and for the next two years studied (full time) electronics, DC/AC, passive circuits, transistors, amplification, RF, telephone systems, power/motors etc, microprocessors, digital systems, lots of hands on work with scopes, soldering and stuff, a pretty dense two year education, approx at least the first year of an EE degree IMHO.

After I finished I did some more writing for about a year, just living an ordinary life in Liverpool and still reading everything I could find on electronics and computing, this is around 1980/1981.

I started to look for a job - hugely wanted an electronics job, I had very good marks from college, several published articles in my portfolio and so on, but could not find work, Liverpool was depressed, high unemployment, factories closing and a few jobs I did interview for outside of Liverpool never materialized, I think not having a proper degree was a handicap too, despite my definite competence and skills.

By fluke a friend mentioned a new 14 week government run course in Liverpool, taught by a private firm, subsidized by the government to deal with high unemployment. Two hundred applied for twenty places, I was one of those that got through the lengthy test process.

I was asked to choose between training in IBM Assembler, COBOL and PL/I. A friend said "PL/I's a pretty serious language, great for writing systemy stuff" so I said OK what the heck and chose that.

Toward the end the firm made efforts to get us interviews, I got one in Enfield, London and they offered me a job, so I left home and started working for the local government as a trainee PL/I programmer, it was nice, decent work, lots of older, experienced clever people and several lads about my age all interested in microprocessors, BASIC, assembler, electronics, Apple etc.

I learned a lot about large scale projects, working in a team, paying attention to detail, communicating technically with others, I was liked and I liked the place.

I ended up working as a software guy thereafter, my 'dream' of a serious electronics career faded and I became a "developer" and am to this day.

Now, as a trained, educated, intelligent electronics person I was interested to see PL/I's features for bits and storage overlays and pointers and so on, I was very at home with technically oriented software, people gave me "technical" work because I had insights that only an electronics engineer would have,

I took it for granted that many other languages also supported stuff like bits, pointers, offsets etc but slowly realized they did not, as I learned C and other languages I recall thinking "Man, this is crazy, that older mainframe language is way beyond these other languages and it would be much better to write stuff in PL/I than C" and so on.

In a word, most other languages looked feeble, rushed, poorly thought out, clumsy, to me anyway, and recall I was not and am not a lightweight in electronics.

So that's my background and so when I discuss programming languages and MCU programming, I'm not naive as some here might want to think, I am inexperienced specifically with these devices and don't pretend to be an expert but I do know how to develop software, I do understand electronics, I do understand compilers, machine language, assembler, and so on.

So this "new language" if I do take it to the next level, is a very serious subject to me, and I see a place for a language that specifically supports features that will aid in MCU development work, I'm 100% definite about that. It's also very interesting, I've built a large compiler already in the past (and wrote it in C) so I am well aware of what's involved.

The PIC stuff was just comments I'd picked up on other forums, PIC developers griping about how hard it is to use C, it seems PIC is an outlier anyway so nothing to be gained by dwelling on that.

[DiTBho]

whatever

Imagine you were calculating the yield of some process:

Code: [Select]


yield = ((total - defects) / total) * 100;


Then one day you upgrade to v3.4 of newlang only to find your code no longer compiles because newlang now supports iterators and 'yield' can no longer be used that way! Right away we must change code, run unit test, create commits, review code and so on, a total waste of people's valuable time all imposed by a language because the designers didn't think about backward compatibility.

less than two minutes to fix this 

[Siwastaja]

Variable renaming is simple work, you don't need the original developer to do it.

If you are changing to different language version, because you want to use new features (so you will be using the new features, and modifying code, or writing new code), a simple variable renaming is going to be smallest of your problems. You can't avoid unit-testing and testing the whole thing with all the changes.

And if you are not going to make any changes, why change the language version then?

(See, this is the difference between real and made-up problems. Real problems can be difficult, but made-up problems are ridiculous when you look at them closely.)

[DiTBho]

(See, this is the difference between real and made-up problems. Real problems can be difficult, but made-up problems are ridiculous when you look at them closely.)

(indeed)

[Mechatrommer]

its called delusion... and i dont get this "bit field support" delusion in newer languague. C already support it, its the job of compiler to make best use of any available machine specific codes for it.

[tggzzz]

Variable renaming is simple work, you don't need the original developer to do it.
 

Macros can make that non-trivial. In a decent language the source code contains enough information that  an IDE can refactoring - either the declared name or every place the variable name is used.

If you are changing to different language version, because you want to use new features (so you will be using the new features, and modifying code, or writing new code), a simple variable renaming is going to be smallest of your problems. You can't avoid unit-testing and testing the whole thing with all the changes.

And if you are not going to make any changes, why change the language version then?

(See, this is the difference between real and made-up problems. Real problems can be difficult, but made-up problems are ridiculous when you look at them closely.)

Sometimes you have to change because a component within your system has changed and must be updated.

Sometimes you have to change because a component outside your system has changecd, either the API signature of the data passed.

[Sherlock Holmes]

whatever

Imagine you were calculating the yield of some process:

Code: [Select]


yield = ((total - defects) / total) * 100;


Then one day you upgrade to v3.4 of newlang only to find your code no longer compiles because newlang now supports iterators and 'yield' can no longer be used that way! Right away we must change code, run unit test, create commits, review code and so on, a total waste of people's valuable time all imposed by a language because the designers didn't think about backward compatibility.

less than two minutes to fix this 

Why break it in the first place.

[Sherlock Holmes]

Variable renaming is simple work, you don't need the original developer to do it.

If you are changing to different language version, because you want to use new features (so you will be using the new features, and modifying code, or writing new code), a simple variable renaming is going to be smallest of your problems. You can't avoid unit-testing and testing the whole thing with all the changes.

And if you are not going to make any changes, why change the language version then?

(See, this is the difference between real and made-up problems. Real problems can be difficult, but made-up problems are ridiculous when you look at them closely.)

Imagine we have twenty source files, all comprising some stable deliverable, it works, its tested.

We want to leverage new async support (say) and that means we'll be changing the implementation of source file number 6, so we do that, we edit it and make the change.

Then we try to build the app again and find it fails to build, what was formerly valid code is now invalid, what was formerly free of syntax errors, now contains syntax errors. Worse still the offending code is in an include file used by twenty other unrelated projects, now we can't build any of those projects without changing that shared file, unless we remember to only use the new version of the compiler on this one file, yes, that'll work...

So we edit that include file and change the function in there (that was named 'async') to some new name like 'basync', all good, we run our rebuild.

But oh dear, there are umpteen places where that function 'async' was being called and include files too, so now we must edit fifteen files in unrelated projects that are referring to a function that we just renamed, but we first have to identify all those unrelated projects  - oh dear.

Even worse, recall all that documentation you wrote and shared with the overseas office? the documentation that explained the design of the function named 'async', you know, that core function that everything hinges on, well you'll have to edit and update all of the documentation and send emails to everyone that might be impacted because you're on vacation next week yet Jane in Spain is due to take the code for a demo, the code that she'll be referring to in her PowerPoint slide show to the important German customer, where the PowerPoint slides discuss the important function named 'async'.

Its at this point that most seasoned developers will say "WTF, why did they have to add that new keyword and cause all this hassle, what numpties are these that develop these languages".

See? this is the difference between real software development and pretend software development, where time, costs, impact don't matter - which is ridiculous of course isn't it...

[DC1MC]

Well, I'm a simple down to earth guy, not an architecture astronaut, so if some one has time, skills and interest in improving a language, why not not get a pre-existing C compiler, a simple version like TinyCC, or LCC, or even SDCC and implement some of the proposed feature in the first posts instead of going into demented syntax and paradigms from long lost languages suitable for long lost platforms and that they were proved hard to use and mostly useless at the time when they were hot and teached in schools and universities.
You know these paradigms that promise that if you throw away all your experience and way of thinking, followed by all previous source code and libraries, you'll get some new and vastly improved way of doing things, one has only to re-learn everything and sky is the limit. This (IMHO) failed before and will fail now as well.
Instead let's implement the low hanging fruits properly in C, I'l put here the low-hanging fruits that I would like to have in a C compiler (extension) and that doesn't need a new grammar or crazy syntax:

- binary representation of numbers: make 0y11_101_1_00 possible, with _ as group separator to make life easier, add some common sense rules of filling values depending of the left size and throwing warning or errors if there are more bits in the source as in the destination,

- introduce a:
#pragma cycle_critical start <max cycle number>
code..
#pragma cycle_critical stop
to enable sections of code that are critical, if the back-end knows how to generate such a code it will do best effort to fit the code in the number of given cycles, or spit out warnings/errors like: "WARNING: Implementation possible in XXX cpu cycles, offered YYY...", if not it will be just ignored (maybe with warnings) to keep compatibility.

- computed gotos, here I don't know how to offer a proper syntax, maybe use @labels everywhere and put them in an enum/pointers array or something that can be used for calculations ?

If somebody will be able to implement this in a sane way in one of the existing C/C++ compilers suitable for MCUs (see above) it will definitely get my full respect, maybe even some shekels if it works nicely and the result will even have a chance to be used by more than two people  . Otherwise I feel the will be yet another implementation of brainfuck.

Just my two humble € cents, now three fiddy because of inflation.

 Cheers,
 DC1MC

[Sherlock Holmes]

its called delusion... and i dont get this "bit field support" delusion in newer languague. C already support it, its the job of compiler to make best use of any available machine specific codes for it.

Not this again. Try reading carefully what I write. I said that C "has no bit data type" I did not say C has no support for bit fields. Yes you can write almost anything in C, I know that I wrote a large compiler in C, remember? You can write anything in assembler too, is that an argument for not using C?

Lets paraphrase what you just wrote:

Assembly language already support it, its the job of assembler to make best use of any available machine specific codes for it.

If your satisfied and content using C then I'm happy for you, this thread is about the issues and features that emerge when discussing what a new better language might look like, might do.

[Sherlock Holmes]

Well, I'm a simple down to earth guy, not an architecture astronaut, so if some one has time, skills and interest in improving a language, why not not get a pre-existing C compiler, a simple version like TinyCC, or LCC, or even SDCC and implement some of the proposed feature in the first posts instead of going into demented syntax and paradigms from long lost languages suitable for long lost platforms and that they were proved hard to use and mostly useless at the time when they were hot and teached in schools and universities.
You know these paradigms that promise that if you throw away all your experience and way of thinking, followed by all previous source code and libraries, you'll get some new and vastly improved way of doing things, one has only to re-learn everything and sky is the limit. This (IMHO) failed before and will fail now as well.
Instead let's implement the low hanging fruits properly in C, I'l put here the low-hanging fruits that I would like to have in a C compiler (extension) and that doesn't need a new grammar or crazy syntax:

- binary representation of numbers: make 0y11_101_1_00 possible, with _ as group separator to make life easier, add some common sense rules of filling values depending of the left size and throwing warning or errors if there are more bits in the source as in the destination,

- introduce a:
#pragma cycle_critical start <max cycle number>
code..
#pragma cycle_critical stop
to enable sections of code that are critical, if the back-end knows how to generate such a code it will do best effort to fit the code in the number of given cycles, or spit out warnings/errors like: "WARNING: Implementation possible in XXX cpu cycles, offered YYY...", if not it will be just ignored (maybe with warnings) to keep compatibility.

- computed gotos, here I don't know how to offer a proper syntax, maybe use @labels everywhere and put them in an enum/pointers array or something that can be used for calculations ?

If somebody will be able to implement this in a sane way in one of the existing C/C++ compilers suitable for MCUs (see above) it will definitely get my full respect, maybe even some shekels if it works nicely and the result will even have a chance to be used by more than two people  . Otherwise I feel the will be yet another implementation of brainfuck.

Just my two humble € cents, now three fiddy because of inflation.

 Cheers,
 DC1MC

Sure that's an option, just grab C and its broken inflexible grammar and add to the mess, that's what they did to get C++, see how well that worked out? today considered the most difficult language to parse and extend.

Take a look at this

C++03's parser defines “>>” as the right shift operator or stream extraction operator in all cases. However, with nested template declarations, there is a tendency for the programmer to neglect to place a space between the two right angle brackets, thus causing a compiler syntax error.

Get that? until 2011 one had to use a space in stuff like this:

Code: [Select]

List<Frame<int> > items;

Omit that space and OH BOY, the parser sees a right shift operator and all hell breaks lose...




As for "demented syntax" you'll need to formally define that for me, might you actually mean unfamiliar perhaps?

[Mechatrommer]

Assembly language already support it, its the job of assembler to make best use of any available machine specific codes for it.

no! assembly is 1 to 1 map to machine code, no need to translate in any fancier way. assembler is just that, 1 to 1 mapping.. duh! how you can make such conclusion?

[DiTBho]

if some one has time, skills and interest in improving a language, why not not get a pre-existing C compiler

That's precisely what I did with my-c
So, it can be done!

[Sherlock Holmes]

Assembly language already support it, its the job of assembler to make best use of any available machine specific codes for it.

no! assembly is 1 to 1 map to machine code, no need to translate in any fancier way. assembler is just that, 1 to 1 mapping.. duh! how you can make such conclusion?

It's a language too, assembler can do anything (and more) that C can do.