The Imperium programming language - IPL

[cfbsoftware]

Now back to me, the language designer working on v 2.0, in this new version we are seeking to add a new keyword to represent asynchronous IO and choose the keyword "async" what will happen when we compile your code, using v2.0 (where "async" is now a new reserved word)?

The most common initial complaint I hear from newcomers to languages like Oberon and Modula-2 are their use of case-sensitive identifiers and all-uppercase reserved words.

However, a significant benefit of these features are that name clashes of this sort never happen - unless you are in the habit of using all-uppercase identifiers in your own code. You can also freely use lowercase or mixed-case identifiers in your own code without ever having to think about existing reserved words.

[SiliconWizard]

Now back to me, the language designer working on v 2.0, in this new version we are seeking to add a new keyword to represent asynchronous IO and choose the keyword "async" what will happen when we compile your code, using v2.0 (where "async" is now a new reserved word)?

The most common initial complaint I hear from newcomers to languages like Oberon and Modula-2 are their use of case-sensitive identifiers and all-uppercase reserved words.

However, a significant benefit of these features are that name clashes of this sort never happen - unless you are in the habit of using all-uppercase identifiers in your own code. You can also freely use lowercase or mixed-case identifiers in your own code without ever having to think about existing reserved words.

While I don't like those all uppercase keywords all that much, you make a good point.

[Siwastaja]

if you have existing code base you have to mantain, you don't have to suddntly use v2.0 in that project if you don't need features from 2.0, there are many compilers that give an option to use a certain version of the language

People miss this all the time when complaining about trivial namespace clashes. Changing to a new language version is like changing to a different language, just smaller change, but it doesn't just happen. So geez, just keep using the language version you are using, nothing suddenly breaks. If you truly find a new language version to provide some significant improvement to warrant an update of the project to new language version (1% likely), and if it happens some new keyword clashes with a variable name in your project (0.1% likely; total 0.001%), then rename the damn variable (usually 5-minute job, but in 1% cases (approaching 0.00001% total), maybe there is more to it and it takes a full day).

Ecosystem is important. The good feature in C ecosystem is, language versions are actually standardized, and compilers target specific versions (usually chosen by a command line flag). It's not a mess like python where you have two totally incompatible versions and some magical "python" symlink where you don't know if it launches python2 or python3.

As always, made-up solutions to made-up "problems". Look at C, C does this right, as usual, as much as people choose to hate it. (And no, this still is not a personal attack).

[Siwastaja]

Thinking about it.. You know one feature that C doesn't really have but that i would like to have in a language?
I would like to have such options to be present in a source file:
The reason is, let's say i want this particular code file to compile with a specific version of the language, or with this specific option
so that i don't have to remember to do it on every project
Also would be easier to document

Seems nice on surface, but it's a good idea to write a makefile and make that part of your process, i.e., put it in revision control system and mentally treat it as something equally important to all those source files.

You can totally generate different rules (command line options) in makefile on a source file basis. The good side compared to your suggestion is, you don't have to copy-paste the settings to each source file and hope they are kept in sync, because in realistic projects, 99% of files use the same settings 99% of the time, so good to have in one file (makefile).

If you have difficulty remembering the "good" settings, just copy the whole makefile from the previous project - or make yourself a good template. This is what I do.

[JPortici]

Thinking about it.. You know one feature that C doesn't really have but that i would like to have in a language?
I would like to have such options to be present in a source file:
The reason is, let's say i want this particular code file to compile with a specific version of the language, or with this specific option
so that i don't have to remember to do it on every project
Also would be easier to document

Seems nice on surface, but it's a good idea to write a makefile and make that part of your process, i.e., put it in revision control system and mentally treat it as something equally important to all those source files.

You can totally generate different rules (command line options) in makefile on a source file basis. The good side compared to your suggestion is, you don't have to copy-paste the settings to each source file and hope they are kept in sync, because in realistic projects, 99% of files use the same settings 99% of the time, so good to have in one file (makefile).

If you have difficulty remembering the "good" settings, just copy the whole makefile from the previous project - or make yourself a good template. This is what I do.

but then i have to remember to do it every time i use that source file. The point is to not having to remember stuff

[Siwastaja]

If you have difficulty remembering the "good" settings, just copy the whole makefile from the previous project - or make yourself a good template. This is what I do.

but then i have to remember to do it every time i use that source file. The point is to not having to remember stuff

You lost me. Remember to do what exactly? Copying one makefile is too much to remember?

I think the opposite is true. If the compiler options, language standards etc. are specified in source files directly, that's a lot to remember, on every file! I rather copy one file than copy-paste 10 lines of configuration in each project source file.

[Nominal Animal]

but then i have to remember to do it every time i use that source file. The point is to not having to remember stuff

I keep stuff in units; currently one directory per unit test/experiment/detail.  If a file requires special compiler options, or I mix C and C++ (for example because g++ still doesn't support named address spaces, unlike e.g. clang), I document it.  I have a short comment in the Makefile, plus a README in that directory.

My brain capacity is so limited I couldn't remember all the details even if I tried.  Documentation is the tool I use to not be limited by my poor memorization capabilities.  In the end, this has taught me to read documentation and source quite quickly, to find salient points, which helps in many things from debugging to adapting existing code for new uses.  I honestly do not believe for a second that not being able to memorize stuff is a handicap; I actually believe the opposite (never relying on memorizing stuff) is more efficient.

[DiTBho]

I keep stuff in units; currently one directory per unit test/experiment/detail.  If a file requires special compiler options, or I mix C and C++ [..] I document it.  I have a short comment in the Makefile, plus a README in that directory.

I do exactly the same here 

[Sherlock Holmes]

Well I'm encouraged by some recent developments. First the lead engineer on an unrelated foreign language programming system has been helpful and we are in communication.

Second, I have been evaluating Antlr as a possible way to create a parser for a new language, having no reserved words seemed like a stumbling block for Antlr and I thought I'd have to hand craft a parser again, doable but a lot of work.

Well Antlr came through, after a few days experimenting I got what I need, this is not the new language, but a crude test of the grammar that I used with Antlr, this supports keywords as identifiers:

Code: [Select]

call = 1234
goto done
ball = 1234
proc revalidate() { }
call ball()
goto = 999
procedure revalidate() { }
proc = 999;




This is extremely encouraging the effort saved by using Antlr will be huge, seriously huge.

[JPortici]

I meant: just as when using certain compilers you need to add
#pragma pack 1
before defining packed structures, you could add something like
#pragma stdandard C90
so that the whole file will be compiled using C90 rules

one advantage could be that the information is within the source file instead of being in another file in the directory, which may be overlooked when copying/importing

[Sherlock Holmes]

Better examples:

Code: [Select]

call = 1234;

goto done;

ball = 1234;

proc revalidate()
{
;
}
call ball();
goto = 999;
procedure revalidate()
{

}
proc = 999;
ptr->xyz = 2;
proc call ()
{
call goto();

proc inner()
{
do_stuff = 0;
}
}

Parse tree is:

[Sherlock Holmes]

Parse tree

[tggzzz]

If you have difficulty remembering the "good" settings, just copy the whole makefile from the previous project - or make yourself a good template. This is what I do.

but then i have to remember to do it every time i use that source file. The point is to not having to remember stuff

You lost me. Remember to do what exactly? Copying one makefile is too much to remember?

I think the opposite is true. If the compiler options, language standards etc. are specified in source files directly, that's a lot to remember, on every file! I rather copy one file than copy-paste 10 lines of configuration in each project source file.

If it was copying one file, you might have a point. But since every project has different source files/directories/libraries, and the compiler version has changed, that isn't the case.

Normally you will need to extract the command line arguments for the components that are also in the new project, and check to see that "improved" compiler optimisations don't require extra or changed flags. Not trivial, and there is a distinct possibility of error.

Putting comments in the source files isn't a panacea, either.

[DiTBho]

pragma is always bad

[SiliconWizard]

Ecosystem is important. The good feature in C ecosystem is, language versions are actually standardized, and compilers target specific versions (usually chosen by a command line flag).

Not only that, but apart from a very few (that the committee tries to minimize) points, backwards compatibility is largely maintained, which is also a very strong point and makes switching to a newer revision of the standard pretty easy. While breaking backwards compatibility is very common in newer languages.

[Sherlock Holmes]

The grammar is coming along well, Antlr is very impressive, this parses absolutely fine:

Code: [Select]

counter = 100;

/* declare some variables named the same as keywords */

dcl dcl dec based(counter);  /* dcl is a keyword ! */

dcl counter binary;

declare goto binary; /* goto is a keyword ! */



goto call; /* call is a keyword ! */



call declare(); /* declare is a keyword */

call declare (1,2,3);

return (123);

if if = then then
   dcl realm binary;
   call reboot(0);
   go to end;
end;


Yielding this tree:



Note the two forms of goto (PL/I always supported these two forms) cause no issues, not a huge advocate of this but the fact this can be reliably parsed will help with foreign languages that might use multiple terms to express certain actions.

[Sherlock Holmes]

I can feel the power...

Code: [Select]

if if = then then
   dcl realm binary;
   call reboot(0);
   go to end;
else
   return (123);
   if = 44;
   end = then + else;
end;


[rstofer]

If I employed somebody who wrote code like that they would be out of a job the very first day.

Just because you can is not a reason for actually doing.

I am not convinced of the absence of keywords being a good idea.

[Mechatrommer]

thats called reinventing the wheel the wrong way hence my 1st post in this thread still applies, but i would like to be proven wrong though... but if you want to be in the list, be my guest... https://www.hongkiat.com/blog/bizarre-insane-programming-languages/

[Sherlock Holmes]

I can feel the power...

Code: [Select]

if if = then then
   dcl realm binary;
   call reboot(0);
   go to end;
else
   return (123);
   if = 44;
   end = then + else;
end;

(Attachment Link)

There are various reserved words in the C language, such as 'if'.  I suspect, it is because it is known and learnt from experience, that if you don't have enough (of the right kind of) reserved words.  It can lead to too many ways in which programmers can accidentally introduce faults in the source code.  Which (due to the lack of reserved words), can make the compiler, incorrectly ignore without generating any warnings or error messages, mistake(s) in the source code.

Also it can lead to valid source code, which is especially confusing for the unwary programmer.

C is not the best of examples, for my recent posts in this thread.  Because its #define concept, relies on programmer discipline, to not inappropriate use it, to make significantly poor (judgement) quality source code, which is for example, very difficult to understand by anyone, other than the original programmer.

As soon as you commit to distinguishing a keyword from an identifier on the basis of its spelling, rather than its context you pay a price. That price is the inability to freely add new keywords over time.

I do not advocate intentionally naming things the same as a keyword, but that's a style, coding standards issue not a grammar issue.

As many have said already in this thread, a developer should know and understand the programming language they use, not become "confused" over something so basic.

Regarding C, the keywords are not reserved to prevent their use as identifiers but for ease of parsing, also C could never do otherwise given that it (inexcusably) represents (void) function invocation with the name of the function alone and not a keyword, this was a mistake and you and others are still paying the price.

There's nothing complicated about incorporating style diagnostics, polite reminders like "The identifier 'yield' is also a language keyword, consider renaming this for improved readability".

Finally when it comes to enabling confusing looking code, C takes the cake:

Code: [Select]


void f(char *x, char*y, int z)
{
    int z2 = (z + 7) / 8;
    switch (z % 8)
    {
        case 0:
        do
        {
            *x++ = *y++;
        case 7:
            *x++ = *y++;
        case 6:
            *x++ = *y++;
        case 5:
            *x++ = *y++;
        case 4:
            *x++ = *y++;
        case 3:
            *x++ = *y++;
        case 2:
            *x++ = *y++;
        case 1:
            *x++ = *y++;
            } while (--z2 > 0);
    }
}



[DiTBho]

It sucks, but no way 

[SiliconWizard]

Why stop at keywords, you could include operators too (unless you consider them keywords as well?)

[MIS42N]

Going back to the purpose of a programming language. I don't have a definition, but if asked I would say a language which translates intentions described by a human into instruction understood by a computer. Humans tend to ascribe particular meanings to particular words - in English 'if' 'when' 'do' 'then' 'next' all have meanings generally agreed on by people who speak the language. What is the problem reserving those words in a computer language to function somewhat like they do in the English language. I see no reason to allow a programmer to bend that.

What should be considered is what are common human intentions that need to be translated to computer speak. And since this discussion is about microcontrollers, one might add the condition "efficiently". There are plenty of languages that can create bloat, and for many application/processor combinations bloat can be tolerated. I was reading recently that micropython "is compact enough to fit and run within just 256k of code space and 16k of RAM". The BASIC in C64 et al was 8k of code for comparison, yet provided a reasonable subset of micropython capability. Much of the increase is not due to the language itself, but the inbuilt support libraries.

This is why I support the idea of adding computed goto, bit fields, packed decimal etc to the language. They are readily understood human constructs that need translating, their inclusion should enhance the chance that the compiler can generate more efficient code. After all, a computed goto in most languages could be written if 1 goto A1 else if 2 goto B1 else if 3 ...  - so there is no need for a specific computed goto construct, but it makes writing and reading easier.

But I think this discussion is likely to lead nowhere because millions of man hours and countless numbers of academics have pored over this problem for decades. What chance this discussion will have some breakthrough that wasn't considered before? I vote for 'fat' - but it would be nice to be wrong.

There are already languages designed for different purposes. I prefer assembler because I have plenty of time on my hands and I can churn out 20 or 30 lines an hour with a high chance it will work. Much of this is down to preparation - flow charts, modelling in another language (you maybe aghast to know my preferred is visual basic script), writing code that gets bashed rather than have dags that rarely if ever get called - e.g. lookup table rather than case statement. And documentation. Looking back at 10 lines of code I wrote weeks ago I can go WTF but then read the 3 or four lines of explanation and go oh, yeah - that's what it does.

Anyhow, just trying to derail this discussion about syntax and point back to why we have programming languages. I think that has been pushed down by trivialities.

[Siwastaja]

I can feel the power...

Code: [Select]

if if = then then


And I guess this is the first crucial step to enable your embedded friends write cycle-accurate code for PIC microcontrollers, yeah?

[DC1MC]

I can feel the power...

Code: [Select]

if if = then then


And I guess this is the first crucial step to enable your embedded friends write cycle-accurate code for PIC microcontrollers, yeah?

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