The Imperium programming language - IPL

[DiTBho]

Yup, it seems fine 

[Sherlock Holmes]

For anyone interested in programming language history, I found this fascinating memoir from one of the members of the committee who were tasked with addressing the problems of having COBOL for business and Fortran for science. IBM wanted to have a single language that could benefit both kinds of customers plus customers who were more focused on general computer science.

The costs of maintaining two distinct languages and creating compilers for their newer emerging hardware, for these two languages, was a real material cost that they wanted to address. Also (as I read in the paper) there was a growing trend where business customers were starting to do some science related coding and scientific customers were starting to do some business related, so there was definite customer desire for a single "universal" language, anyone, you can read this if it interests you...

[newbrain]

It could be extended too so that we can do this to a structure, where all endian dependent members are automatically taken care of:

Code: [Select]

data_header = LittleEndian (data_header);
Where data_header is an aggregate like an array/structure or both, this would impact numeric fields, floats and pointers/offsets even...

The version working on a single, not structured, variable is best suited to a default library, it should not be part of the language, same goes with the endianness check.

The extended version, though, looks a bit too 'magic'.

I clarify: would a user of the language be able to implement a similar fully generic function using the language itself?
It seems that some deep introspection capabilities would be needed, I don't think you mentioned them before (I might have missed them).
If not, it should be clear for the reader that this is not a regular function (BTW: I hated I could not write a write() in Pascal).

The same goes with passing arguments of different types (and this is valid also for the simple version!): the type model of this now language is totally unclear to me, as are the memory model and the execution model*.
Also: how modules are handled, though this too might have escaped my attention.

In this thread I have mostly seen syntax (not a fan, but to each their own - and not a problem unless it's obnoxious) which I think should be a lesser concern and random bits and pieces.

*Apart from the "constant cycle duration switch", which is impossible to achieve if not in the trivial cases, even forgetting about modern HW, unless someone has disproved Turing's halting theorem.

[Sherlock Holmes]

One final note: Classical if - then - elseif - else probelm. My suggestion is something like this:

Code: [Select]

if (expr)
  stmts;
elif (expr)
  stmts;
else
  stmts;
endif
Thus a simple test:

Code: [Select]

if (expr)
  stmts;
endif
A simple test with else clause:

Code: [Select]

if (expr)
  stmts;
else
  stmts;
endif
etc.

This is certainly an interesting grammar design question. First though when you say "problem" what do you mean? Do you mean it presents a parsing challenge or a cognitive challenge to a human reader?

The "elif" does improve readability I think, this parses fine:

Code: [Select]

if count > 100 then
   call do_something();
else
   if count < 0 then
      call do_something_else();
   else
      if count > max then
     call where_done();
              end;
           end;
end;




But is increasingly indented, so I agree that an "elif" is very helpful here and we end up with just the one "end", let me tweak the grammar and see...

[Kalvin]

One final note: Classical if - then - elseif - else probelm. My suggestion is something like this:

Code: [Select]

if (expr)
  stmts;
elif (expr)
  stmts;
else
  stmts;
endif
Thus a simple test:

Code: [Select]

if (expr)
  stmts;
endif
A simple test with else clause:

Code: [Select]

if (expr)
  stmts;
else
  stmts;
endif
etc.

This is certainly an interesting grammar design question. First though when you say "problem" what do you mean? Do you mean it presents a parsing challenge or a cognitive challenge to a human reader?

C and C++, as well as some Algol-languages, may suffer more or less from so called dangling else syndrome.

https://en.wikipedia.org/wiki/Dangling_else

Adding this endif keyword will fix potential grammar ambiguity, help with parsing, and also help the human reader.

This is a simple error to make in C-family languages, but sometimes hard to spot:

Code: [Select]

if (expr)
  stmt;
  stmt;
When the if-statement block will always end with endif keyword, this problem will be fixed. And no braces are required, either.

Code: [Select]

if (expr)
  stmt;
  stmt;
endif
I would fix the while-statement and for-statement, as well.

Code: [Select]

while (expr)
  stmts;
endwhile

Code: [Select]

for (for-loop-control-block)
  stmts;
endfor
Whether to use endwhile and endfor, or just plain end, I do not have any strong opinion. The idea is just to avoid those easy-to-make human errors and help the parser with detecting errors.

While at talking about the C-language, grammar and braces, it would be nice if the language would be cleaned up so that the braces could be eliminated as much as possible. The function-blocks, struct and enums etc. could be defined so that no braces are required, and the end of the blocks would contain just an end keyword instead.

[Siwastaja]

While at talking about the C-language, grammar and braces, it would be nice if the language would be cleaned up so that the braces could be eliminated as much as possible.

Why would you want to eliminate braces as much as possible? One can disagree about the exact symbol ({ } instead of something else like ( ) or begin end), but braces in syntactically C-like language do excellent job by visually and logically grouping things together - statements in code, variables in a struct, values in compound initializer, and so on. Prefer explicit over implicit; explicit grouping, in this case. Typing the braces is little work, and can be further automated in an IDE.

As a beginner, I wanted to "eliminate braces" to make code look smaller, but nowadays I find myself doing the opposite; one can group related statements in a { } block even if that isn't strictly necessary, creating a local "namespace", and making later refactoring into a function more obvious.

[Sherlock Holmes]

One final note: Classical if - then - elseif - else probelm. My suggestion is something like this:

Code: [Select]

if (expr)
  stmts;
elif (expr)
  stmts;
else
  stmts;
endif
Thus a simple test:

Code: [Select]

if (expr)
  stmts;
endif
A simple test with else clause:

Code: [Select]

if (expr)
  stmts;
else
  stmts;
endif
etc.

This is certainly an interesting grammar design question. First though when you say "problem" what do you mean? Do you mean it presents a parsing challenge or a cognitive challenge to a human reader?

C and C++, as well as some Algol-languages, may suffer more or less from so called dangling else syndrome.

https://en.wikipedia.org/wiki/Dangling_else

Adding this endif keyword will fix potential grammar ambiguity, help with parsing, and also help the human reader.

This is a simple error to make in C-family languages, but sometimes hard to spot:

Code: [Select]

if (expr)
  stmt;
  stmt;
When the if-statement block will always end with endif keyword, this problem will be fixed. And no braces are required, either.

Code: [Select]

if (expr)
  stmt;
  stmt;
endif
I would fix the while-statement and for-statement, as well.

Code: [Select]

while (expr)
  stmts;
endwhile

Code: [Select]

for (for-loop-control-block)
  stmts;
endfor
Whether to use endwhile and endfor, or just plain end, I do not have any strong opinion. The idea is just to avoid those easy-to-make human errors and help the parser with detecting errors.

While at talking about the C-language, grammar and braces, it would be nice if the language would be cleaned up so that the braces could be eliminated as much as possible. The function-blocks, struct and enums etc. could be defined so that no braces are required, and the end of the blocks would contain just an end keyword instead.

Well said, I've done exactly that with this new grammar, PLI used:

Code: [Select]


if expression then
   do;
   stmt;
   stmt;
   end;
else
   do;
   stmt;
   stmt;
   end;

But the "if" can be easily matched with an "end" and so removes the distinction between single statements and multiple statements within the then/else clauses.

The block delimiters just consume lines, real estate too, not a huge problem but wasteful of screen real estate.

For some time now I've argued that the C grammar has negatively impacted programming language design. It's crippled IMHO and this has had consequences for C++, Java, C# etc. adding new keywords often requires syntax acrobatics to get it right.

Check this out: https://blog.paranoidcoding.com/2022/04/11/lowercase-type-names.html

[Kalvin]

While at talking about the C-language, grammar and braces, it would be nice if the language would be cleaned up so that the braces could be eliminated as much as possible.

Why would you want to eliminate braces as much as possible? One can disagree about the exact symbol ({ } instead of something else like ( ) or begin end), but braces in syntactically C-like language do excellent job by visually and logically grouping things together - statements in code, variables in a struct, values in compound initializer, and so on. Prefer explicit over implicit; explicit grouping, in this case. Typing the braces is little work, and can be further automated in an IDE.

As a beginner, I wanted to "eliminate braces" to make code look smaller, but nowadays I find myself doing the opposite; one can group related statements in a { } block even if that isn't strictly necessary, creating a local "namespace", and making later refactoring into a function more obvious.

How many formatting styles there are for the braces, and how many fights there have been between project members how the braces should be placed in the source code.  Anyway, in my opinion most of the braces are just superfluous, and they should be replaced by grammatical constructs that reduce or eliminate the use of braces as much as possible.

[SiliconWizard]

Well, not using braces sure avoids fights about how to place them in source code.
I still find curly braces nice block delimiters and the choice is not random, it comes from math notation.
Let people use their favorite code style, who cares. There are more important things in engineering than deciding where to put braces. It doesn't fricking matter as long as readability is preserved.

But anyway, again most of what we can read in this thread is about grammar and syntax, and very little if anything about fundamental concepts of programming.
The contract thing is one of the rare exceptions here. But it's nothing new either, it's in Ada 2012, has been in Spark for longer than this, and in Eiffel longer ago yet, and a (albeit small) number of other languages. This is definitely an interesting and important feature and definitely not trivial to implement properly.

[Sherlock Holmes]

There are more important things in engineering than deciding where to put braces. It doesn't fricking matter as long as readability is preserved.

Well, discuss some then.

But anyway, again most of what we can read in this thread is about grammar and syntax, and very little if anything about fundamental concepts of programming.

The contract thing is one of the rare exceptions here. But it's nothing new either, it's in Ada 2012, has been in Spark for longer than this, and in Eiffel longer ago yet, and a (albeit small) number of other languages. This is definitely an interesting and important feature and definitely not trivial to implement properly.

This is simply wrong, totally misrepresentative of the discussion, I and a few others have discussed a host of areas, like

memory alignment, field ordering, padding
big/little endian issues
coroutines and cofunctions
exception support
runtime checks
fixed point arithmetic
nested procedures/functions
argument passing
contracts
computed goto
offsets (as opposed to pointers)
array and string metadata
bit data type support

and more, all of these are mentioned somewhere or other in this thread.

Finally if you care so little about grammar, syntax, if this is so little importance to you, why not just use assembler? why would you use anything other than assembler?

[DiTBho]

Well, not using braces sure avoids fights about how to place them in source code.

my-c also comes with a code-beautifier.

Code: [Select]

# my-c --fo file.myc
won't compile the source, instead it will parse file.myc and output it well formatted.
(it makses sense because the code-viewer, the program that interfaces the ICE, needs the code formatted in a specific way)

problem solved

[brucehoult]

I don't need you to be a dictionary.  I just need you to use the English language well.
Porn website.
Spoken like a hack.
Where you live perhaps.

Alright, enjoy my ignore list.

Indeed so. Along with Sherlock.

[MIS42N]

I'm not proposing a language, go on, check all the posts for yourself. You can't talk about language as distinct from "how it is expressed", that IS LANGUAGE. We can't even discuss languages without using a language, anyway, I'm tired, good night.

Of course language and what is being expressed are separate:
çfarë është dy plus dy
Co je dva plus dva
ni nini mbili pamoja na mbili
Kas ir divi plus divi
All express the same concept but in different languages. If we want X to be the sum of Y and Z one language will say X=Y+Z another will say push Y push Z add pop X (perhaps symbolically). What I want of a language is can it add two numbers efficiently, and I don't care what I have to say to get it to happen.

In fact the more I look at this thread the more I lean toward assembler. A recent program does a lot of arithmetic but does not need to be efficient. So I took an old PIC arithmetic package I've used for years, copied stack functionality from a previously written program, rewrote the push and pop routines in this program to use the enhanced PIC architecture but the macro remains the same. For example PushU2 fred pushes an unsigned integer onto the stack in both programs, but the underlying code is different. So it seems what I am doing is inventing a new language (or a few new words) for each program. The top octave generator had NOTEPROC x, INSERTR x, EPILOG, ONEOUT, SEVENOUT, INTEXIT. Because of the need for efficiency and timing, it was not possible to use subroutines in most places, so inline code was repeated in many places. Part of the problem being the need to keep the output aligned on 500ns boundaries. To do that required synchronizing code in the ISR to delay between 0 and 2 cycles, CALL and RETURN would require 0 to 3 cycles which was much harder to do and wasted too much time (I think the CPU utilization is around 97%).

Maybe my world view is too narrow for this thread.

[Sherlock Holmes]

One final note: Classical if - then - elseif - else probelm. My suggestion is something like this:

Code: [Select]

if (expr)
  stmts;
elif (expr)
  stmts;
else
  stmts;
endif
Thus a simple test:

Code: [Select]

if (expr)
  stmts;
endif
A simple test with else clause:

Code: [Select]

if (expr)
  stmts;
else
  stmts;
endif
etc.

OK I adjusted the grammar and this parses fine now:

Code: [Select]

if count > 100 then
   call do_something();
elif count < 0 then
   call do_something_else();
elif count > max then
   call where_done();
else
   return;
end;

As do any of the multitude of variants you can envisage. I like this a lot, "elif" is a very helpful addition to the grammar! Here's the parse tree for the above fragment:



Naturally any if, else or elif clause can have one or more statements, that example has only one in each case.

[Sherlock Holmes]

This is fascinating, this test failed to parse:

Code: [Select]

if count > 100 then
   call do_something();
elif count < 0 then
   call do_something_else();
   call do_whatever();
elif count > max then
   call where_done();
   if we_are_still_here then
      return;
   elif we_did_not_crash then
      call crash();
   else
      call stop();
else
   return;
end;

I was puzzled, staring at the source, the parse tree, the Antlr grammar etc then I noticed the embedded IF itself needed and "end" (highlighted below as uppercase)

Code: [Select]

if count > 100 then
   call do_something();
elif count < 0 then
   call do_something_else();
   call do_whatever();
elif count > max then
   call where_done();
   if we_are_still_here then
      return;
   elif we_did_not_crash then
      call crash();
   else
      call stop();
   END;
else
   return;
end;

Note to self: when testing a grammar MAKE BLOODY SURE THE INPUT TEXT IS SYNTACTICALLY VALID !

The grammar for IF is basically: IF <expression> THEN <statements>  (optional ELSE/ELIF clause) END;, i.e. every IF must have an associated END, all good, it now parses fine!

[Kalvin]

About code generation and compiler optimization: There are already quite many open source compilers which provide optimized code generation, along with a full tool-chain, thus inventing a wheel may not be necessary. If the parser for a new language syntax could produce an AST which is compatible with the existing compiler technology, the customized compiler front end could be used with the existing compilers which would simplify the whole process.

The GNU compiler suite is using this approach, as there is a language-specific front-end coupled with a generic/universal back-end which is not targeted to any particular language or architecture what so ever. Unfortunately I do not know the internals of the GNU compiler suite, so I cannot provide any detailed information how hard this approach would be. However, since the source code for the GNU compiler suite is freely available, it might be possible to figure out what is takes to create a new front end for a new language. Of course any other freely available compiler suite would be a good candidate, too.

Before writing a full-blown compiler, one could create a source code translator for the new language producing valid C language (for example). This would simplify the process of trying out and prototyping different constructs in the new language.

[DC1MC]

About code generation and compiler optimization: There are already quite many open source compilers which provide optimized code generation, along with a full tool-chain, thus inventing a wheel may not be necessary. If the parser for a new language syntax could produce an AST which is compatible with the existing compiler technology, the customized compiler front end could be used with the existing compilers which would simplify the whole process.

The GNU compiler suite is using this approach, as there is a language-specific front-end coupled with a generic/universal back-end which is not targeted to any particular language or architecture what so ever. Unfortunately I do not know the internals of the GNU compiler suite, so I cannot provide any detailed information how hard this approach would be. However, since the source code for the GNU compiler suite is freely available, it might be possible to figure out what is takes to create a new front end for a new language. Of course any other freely available compiler suite would be a good candidate, too.

Before writing a full-blown compiler, one could create a source code translator for the new language producing valid C language (for example). This would simplify the process of trying out and prototyping different constructs in the new language.

Yesss, yesss, translate it to C, "The only true systems languagage" ᵀᴹ , the first C++ "compilers" did the same  .

[tggzzz]

About code generation and compiler optimization: There are already quite many open source compilers which provide optimized code generation, along with a full tool-chain, thus inventing a wheel may not be necessary. If the parser for a new language syntax could produce an AST which is compatible with the existing compiler technology, the customized compiler front end could be used with the existing compilers which would simplify the whole process.

The GNU compiler suite is using this approach, as there is a language-specific front-end coupled with a generic/universal back-end which is not targeted to any particular language or architecture what so ever. Unfortunately I do not know the internals of the GNU compiler suite, so I cannot provide any detailed information how hard this approach would be. However, since the source code for the GNU compiler suite is freely available, it might be possible to figure out what is takes to create a new front end for a new language. Of course any other freely available compiler suite would be a good candidate, too.

Before writing a full-blown compiler, one could create a source code translator for the new language producing valid C language (for example). This would simplify the process of trying out and prototyping different constructs in the new language.

Yesss, yesss, translate it to C, "The only true systems languagage" ᵀᴹ , the first C++ "compilers" did the same  .

So did Kyoto Common Lisp.

Nowadays people tend to use a well-defined architecture-neutral intermediate representation that is available, supported (and debugged) on a variety of architectures. It even has multithreading and multiprocessing.

[brucehoult]

About code generation and compiler optimization: There are already quite many open source compilers which provide optimized code generation, along with a full tool-chain, thus inventing a wheel may not be necessary. If the parser for a new language syntax could produce an AST which is compatible with the existing compiler technology, the customized compiler front end could be used with the existing compilers which would simplify the whole process.

The GNU compiler suite is using this approach, as there is a language-specific front-end coupled with a generic/universal back-end which is not targeted to any particular language or architecture what so ever. Unfortunately I do not know the internals of the GNU compiler suite, so I cannot provide any detailed information how hard this approach would be. However, since the source code for the GNU compiler suite is freely available, it might be possible to figure out what is takes to create a new front end for a new language. Of course any other freely available compiler suite would be a good candidate, too.

Before writing a full-blown compiler, one could create a source code translator for the new language producing valid C language (for example). This would simplify the process of trying out and prototyping different constructs in the new language.

Yesss, yesss, translate it to C, "The only true systems languagage" ᵀᴹ , the first C++ "compilers" did the same  .

There is no reason to put the word "compilers" in scare quotes. Compiling to C is every bit as valid as compiling to assembly language.

The question to ask is this: if you make an error in your C++ code, will you get an error message from the C++-to-C compiler, or from the C compiler?

If the answer is ever "the C compiler" then that's a bug in the C++-to-C compiler, plain and simple.

And it didn't happen with CFront. Not even in 1989.

[Sherlock Holmes]

So far as code generators go, LLVM seems to be the ideal way to do that. I've never used it but it seems hugely capable, so were I taking this forward in earnest, that would be my focus. Interestingly too Antlr4 does not support automatic AST building, so some effort seems likely to deal with that (it generates a grammar derivation tree "parse tree").

Generating C is an attractive idea too, it could serve as a proof of concept. But this would still be some serious work, it would require a C abstract machine idea of sorts, that would need to expose stack, push pop to/from the stack, etc. Unless one wanted to simply translate code fragments into C, but that assumes a great deal, the semantics of C can't be assumed to be the semantics of the source language.

For example C has no function nesting, representing that - in a general way - in C requires abstracting the concept, this is why a more machine like abstraction might be better, in fact generating assembly language embedded in C might be better then a C dev environment could be used as is.

One could craft a set of C functions that generate standard chunks of assembler for block entry, exit and so on. It might even be possible to build a contiguous block of memory this way and then forcibly begin execution of it once done. Rather than generating inline assembler, generate it into some address, some buffer...in fact that sounds a lot like a useful new language feature!

[Kalvin]

For example C has no function nesting, representing that - in a general way - in C requires abstracting the concept, this is why a more machine like abstraction might be better, in fact generating assembly language embedded in C might be better then a C dev environment could be used as is.

GNU C has an extension for function nesting.

[Sherlock Holmes]

https://asmjit.com/

[Sherlock Holmes]

I've managed to get Antlr to recognize the grammar's support for numeric literals in multiple bases and which can contain readability spaces (or underscore) as separators. All of these are recognized:

Code: [Select]

proc test(x)

value = DEF ABC 2DC0 6BA0:h * 100; // note, no more than a single space can be the separator.

call reboot(FACE DEFB 10C0:H + 239:H);

value = 100 123.45;

value = 1011 FC4.7F:h;

value = 1010 1010;

value = 123:d;

value = 1010 1010:b;

octal = 765:o;

end;


There are four kinds of numeric literals, binary, octal, decimal and hex, they all need a colon-char base designator except dec, for which this can be omitted.

[Kalvin]

I've managed to get Antlr to recognize the grammar's support for numeric literals in multiple bases and which can contain readability spaces (or underscore) as separators. All of these are recognized:

Code: [Select]

proc test(x)

value = DEF ABC 2DC0 6BA0:h * 100; // note, no more than a single space can be the separator.

call reboot(FACE DEFB 10C0:H + 239:H);

value = 100 123.45;

value = 1011 FC4.7F:h;

value = 1010 1010;

value = 123:d;

value = 1010 1010:b;

octal = 765:o;

end;


There are four kinds of numeric literals, binary, octal, decimal and hex, they all need a colon-char base designator except dec, for which this can be omitted.

Personal opinion: I do not like spaces in the literals. Underscore, for example, would be better.

From the tokenizer/parser point of view things would be much easier if the spaces would not be allowed in literals. See also my comment about the tools below.

Edit: There has also been some discussion on how to group the digits in numerical literals. I guess that it would be possible to build a simple tool using regexpr rule(s) for checking the grouping of the digits for floating point, decimal, hex, octal and binary numbers of person's liking. Just run the checker as part of the build process, and the checker will fail the build process if the numerical literals are using invalid grouping. Building a directive for the rules of digit grouping into the language grammar could be also possible, but I am not sure if that would be a wise choice (without extensive prototyping and evaluation at least).

---

At some point in this thread there was a discussion whether to use reserved words or not. I think the history of the programming languages have shown that using reserved words makes the grammar easier to parse and reduce ambiguity. Just keep the grammar as simple as possible.

About tools: All tools - such as code formatters, IDEs, refactoring tools etc. - would benefit from a simple grammar without ambiguity.

We have something like 70 years of knowledge about programming languages, so there is no need to repeat the problems of the earlier programming languages.

[brucehoult]

For example C has no function nesting, representing that - in a general way - in C requires abstracting the concept, this is why a more machine like abstraction might be better, in fact generating assembly language embedded in C might be better then a C dev environment could be used as is.

GNU C has an extension for function nesting.

You don't need to generate nested functions in the C output to implement source language nested functions.