The Imperium programming language - IPL

[Sherlock Holmes]

So what is it? is the 100 a char or an int? Yes, it IS an int and it is being assigned to a char without a (char) on the basis of your earlier argument about "safety" and "footguns" I must assume that you always insert the (char) in such cases, if not why not?

That's actually a good question. Yes, sometimes I write explicit cast, sometimes not. The reason not to is when it is obvious what is going to happen anyway (I assume the reader knows the basics of the C standard, but don't assume they know every detail by heart). Such case is assigning uint8_t to uint32_t: it is obvious that the input range [0..255] maps to output range [0..255] and extra bits get filled with zeroes.

On the other hand, maybe I want to emphasize the fact extra bits are generated. Not to compiler, but human reader. Then why not add the explicit cast.

Or, when I convert a float to integer, let's say:
double asdf = 123.4;
int val = asdf + 0.5; // round up and truncate after decimal point

One can emphasize the conversion by writing:
int val = (int)(asdf + 0.5);

But, you can just write
int val = asdf + 0.5;

because the implicit conversion does the same.

But explicit makes sense, because the same thing could be used in a more complex expression, where adding the cast does make the difference:
double something_else = (double)(int)(asdf+0.5) * qwerty;

Remember, programming is not only about making compiler happy, but to convey the meaning to human readers, too.

I don't disagree, if something can improve readability I'm all for it, but that's not what I've been arguing. What I said - and it is true - is that deducing the type when assigning {0} to some target is no more unreasonable or risky than deducing the type when I assign a short to a char, in fact it carries less risk.

I really cannot see nor has anyone convincingly explained, the theoretical justification to treat these cases differently, making one of these optional and the other obligatory - especially when the former carries more risk:

Code: [Select]


char X;
Data Y;

X = (char)0;

Y = (Data){0};


If I am allowed to omit the (char) then logically I should also be allowed to omit the (Data), this is all I've been saying, by all means disagree but my argument is not from ignorance or lack of reading literature, it based on the asymmetry, edge case syndrome that the language suffers from.

Anyway the outcome of this for me, is that a universal default() language function/keyword would be a huge help in any language, helping to avoid such gnarly code.

Here is another person's view, someone with plenty of familiarity with the "literature".

I quote:

People get surprisingly defensive about it—perhaps it's Stockholm Syndrome?—but C simply isn't a well-designed language. The fact that the other popular alternatives are more complex and worse (C++? really?) doesn't change that. The fact that you know its edge cases well enough to get by (but probably not well enough to avoid a myriad sources of bugs and security vulnerabilities unique to the language) doesn't change it either.

Here's his blog/website too.

[tggzzz]

If being explicit about the type is so helpful then why do we not see this on every assignment:

The problem with yourself is, because you don't read, you never learn.

Yes, everything does indicate that.

Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.

But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.

Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.

I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.

But, hey, go knock yourself out

What exactly have I written that you regard as untrue?
...

Thereby indicating you didn't read what I wrote.

QED.

[Sherlock Holmes]

If being explicit about the type is so helpful then why do we not see this on every assignment:

The problem with yourself is, because you don't read, you never learn.

Yes, everything does indicate that.

Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.

But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.

Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.

I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.

But, hey, go knock yourself out

What exactly have I written that you regard as untrue?
...

Thereby indicating you didn't read what I wrote.

QED.

Nor will I be reading anything else you write.

[gf]

Code: [Select]

char X;
Data Y;
X = (char)0;
Y = (Data){0};

If I am allowed to omit the (char) then logically I should also be allowed to omit the (Data),

The expression Y={0} were already syntactically wrong, because {0} is not a valid expression according to the language definition.

A philosophy of C is that each expression has its own intrinsic type which does not depend on the context in which the expression is used. Therefore {0} cannot be a valid expression, because no unique type can be deduced from {0} alone. OTOH, the integer literal expression 0 has an intrinsic type (which is int).

EDIT:
Note that (Data){0} is NOT a cast expression, but a compund literal. The (Data) is part of the literal.
OTOH, (char)0 is a cast expression (unary cast operator) which converts the integer literal 0 to type char.

[Sherlock Holmes]

Code: [Select]

char X;
Data Y;
X = (char)0;
Y = (Data){0};

If I am allowed to omit the (char) then logically I should also be allowed to omit the (Data),

The expression Y={0} were already syntactically wrong, because {0} is not a valid expression according to the language definition.

A philosophy of C is that each expression has its own intrinsic type which does not depend on the context in which the expression is used. Therefore {0} cannot be a valid expression, because no unique type can be deduced from {0} alone. OTOH, the integer literal expression 0 has an intrinsic type (which is int).

EDIT:
Note that (Data){0} is NOT a cast expression, but a compund literal. The (Data) is part of the literal.
OTOH, (char)0 is a cast expression (unary cast operator) which converts the integer literal 0 to type char.

Well this also contains an invalid expression then too surely?

Code: [Select]


MyStructure datum = {0};


Logically, in any language I've ever used (including C but like over a decade ago) these were regarded as having identical semantics:

Code: [Select]


short X = 0;

short Y; Y = 0;


Now if they don't (which seems to be the case for {0}) then that's fine, all well and good, but isn't a good language characteristic, this has been my argument all along about this, it's just - not good, these edge cases are the kind of things programming languages are compared on, symmetry, orthogonality, easy to reason about and so on. Unless one knew already that this asymmetry is there one would reason incorrectly.

[tggzzz]

If being explicit about the type is so helpful then why do we not see this on every assignment:

The problem with yourself is, because you don't read, you never learn.

Yes, everything does indicate that.

Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.

But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.

Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.

I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.

But, hey, go knock yourself out

What exactly have I written that you regard as untrue?
...

Thereby indicating you didn't read what I wrote.

QED.

Nor will I be reading anything else you write.

That's consistent.

It would have been more precise if you had written "... be starting to read..."

[gf]

Well this also contains an invalid expression then too surely?

Code: [Select]

MyStructure datum = {0};


In conjunction with the declaration of datum, the ={0} is an initialization, and {0} is still not an expression, but an initializer-list enclosed in braces.
See https://en.cppreference.com/w/c/language/initialization

[Sherlock Holmes]

The lexical analysis for the space separated literals is looking to be done, it has a subtlety that means it cannot be handled by a pure FSM, a stack is required and that means also the this cannot be represented by a regular expression, now I don't know off hand if ANTLR supports that, it might because its described as not being a pure DFA based system.

Anyway I have this working, I have a previously written .Net text-table driven lexical analyzer and it already supports a stack so this was not too much effort.

Anyway, although the grammar is not cast in stone, it has taken shape and now this kind of thing is what it will start to look like:

Code: [Select]


proc initialize (count)
{
   arg count bin(8,2); // fixed point binary, 6.2 format
   dcl register_mask bin(24,8);
   dcl temporary dec(15,3); // fixed point decimal, 12.3 format

   count = 110011.01B;

   temporary = 23 000 000 000.25;

   register_mask = 2F03 D7F8.2:H;

   // Or equivalently

   register mask = 10 1111 0000 0011 1101 0111 1111 1000.00100000:b;

}


Of course underscore's are permitted, not just spaces, but the space/underscore must be a single space/underscore to avoid unsightly stuff developing.









   

[Mechatrommer]

If being explicit about the type is so helpful then why do we not see this on every assignment:

The problem with yourself is...

this is going to be a looong thread

Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.

i mean... there are few members in this forum that are persistent enough to update their tiny progress/thought in their own "log thread" for extended amount of time, grow into hundreds of pages... and then later post the latest update saying the previous posts was a mistake... in the end i only look at the thread when somebody else made a new reply in case they provide new informations... to put insult to the pain... esp "language" is a really subjective matter imho. cheers.

[Sherlock Holmes]

Well this also contains an invalid expression then too surely?

Code: [Select]

MyStructure datum = {0};


In conjunction with the declaration of datum, the ={0} is an initialization, and {0} is still not an expression, but an initializer-list enclosed in braces.
See https://en.cppreference.com/w/c/language/initialization

Yes, what you say is likely absolutely the case, that doesn't justify the design though, in the case of initializing a declaration, populating the lvalue is what happens and there's no need I can see for distinguishing between an lvalue used when we declare vs an lvalue used as the source expression of an assignment.

What I can "do to" the memory associated with some variable shouldn't differ between declaring it and assigning to it, IMHO anyway.

[gf]

Well this also contains an invalid expression then too surely?

Code: [Select]

MyStructure datum = {0};


In conjunction with the declaration of datum, the ={0} is an initialization, and {0} is still not an expression, but an initializer-list enclosed in braces.
See https://en.cppreference.com/w/c/language/initialization

Yes, what you say is likely absolutely the case, that doesn't justify the design though, in the case of initializing a declaration, populating the lvalue is what happens and there's no need I can see for distinguishing between an lvalue used when we declare vs an lvalue used as the source expression of an assignment.

What I can "do to" the memory associated with some variable shouldn't differ between declaring it and assigning to it, IMHO anyway.

The newer stuff is even orthogonal insofar as MyStructure datum = (MyStructure){0}; works as well, and here (MyStructure){0} is indeed an expression which can be also used as RHS of an assignment operator. The "traditional" declaration+initialization syntax MyStructure datum = { initializer-list }; dates back to K&R C, and was obviously retained for compatibility. Typed compound literals were introduced much later.

Still the right hand side of the binary assignment operator must be an expression, and {0} cannot be an expression. If it were a valid expression, then for instance

Code: [Select]

typedef struct { int x; } Data;

int f()
{
    return {0}.x;
}

would be valid as well. But of course this can't work when {0} has no associated type.

OTOH, with a properly typed compound literal (which is a valid expression) it works as expected, and f() returns 0:

Code: [Select]

typedef struct { int x; } Data;

int f()
{
    return (Data){0}.x;
}


[Siwastaja]

OTOH, with a properly typed compound literal (which is a valid expression) it works as expected, and f() returns 0:

Code: [Select]

typedef struct { int x; } Data;

int f()
{
    return (Data){0}.x;
}


Exactly. You can come up with more examples like this - the point is, the grammar and syntax is logical and repeatable.

There already is one "exception" to this logic, namely initializer list being a different animal from compound literal, and not needing a type.

One could argue C should add more of same type of exceptions, like the "in case of assignment to a struct type, compound literal is assumed to have the type of assignment target, unless otherwise explicitly typed". OK, then what? Now we have introduced more rules to the language, and what did we achieve? We saved a few keystrokes, hid the type from view, and you STILL need to write the type in all other forms of expressions.

Such thinking is very superficial. Again, the number of keystrokes needed is unimportant. Having to type something explicitly is a "problem" only for total beginners, who think majority of time spent in programming is hitting the keys. And any of this has absolutely no fundamental effect on the language design. More fundamental is the fact that these expressions have a type which is known at compile time, to both the programmer and the compiler.

[Sherlock Holmes]

OTOH, with a properly typed compound literal (which is a valid expression) it works as expected, and f() returns 0:

Code: [Select]

typedef struct { int x; } Data;

int f()
{
    return (Data){0}.x;
}


Exactly. You can come up with more examples like this - the point is, the grammar and syntax is logical and repeatable.

There already is one "exception" to this logic, namely initializer list being a different animal from compound literal, and not needing a type.

One could argue C should add more of same type of exceptions, like the "in case of assignment to a struct type, compound literal is assumed to have the type of assignment target, unless otherwise explicitly typed". OK, then what? Now we have introduced more rules to the language, and what did we achieve? We saved a few keystrokes, hid the type from view, and you STILL need to write the type in all other forms of expressions.

Such thinking is very superficial. Again, the number of keystrokes needed is unimportant. Having to type something explicitly is a "problem" only for total beginners, who think majority of time spent in programming is hitting the keys. And any of this has absolutely no fundamental effect on the language design. More fundamental is the fact that these expressions have a type which is known at compile time, to both the programmer and the compiler.

This discussion about {0} and the asymmetric way it's handled, combined with the serious problem of it not satisfying the grammar for an expression, is IMHO a good example of the language's many shortcomings, shortcomings that are very hard to address and to improve.

This is also an example of why I place great importance on a grammar, once a grammar is cast in stone it is very hard indeed to change it much, any newer, changed grammar must be able to still consume the earlier grammar.

I've been reading about the Julia language, that is actually refreshingly interesting. It dispenses with the braces as block delimiters, as does Python, but does not rely on indentation like Python (a disaster waiting to happen IMHO). It also dispenses with semicolons, these two features do give it a visual clarity that's nice too look at, but I think it loses an ability to wrap statements across multiple lines, but that's really not a huge deal in this day and age (the semicolon likely originated at a time when lines were 80 chars max).

[Sherlock Holmes]

If semicolons are discarded as statement terminators and line endings adopted instead, and we lose the braces we get something more compact, here's what the earlier fragment becomes:

Code: [Select]

proc initialize (count)

   arg count bin(8,2)  // fixed point binary, 6.2 format
   dcl register_mask bin(24,8)
   dcl temporary dec(15,3)  // fixed point decimal, 12.3 format

   count = 110011.01B

   temporary = 23 000 000 000.25

   register_mask = 2F03 D7F8.2:H

   // Or equivalently

   register mask = 10 1111 0000 0011 1101 0111 1111 1000.00100000:b

end


Semicolons basically become optional, because it and CR/LF are treated in the same way during parsing. Because we have keywords for all executable statements, they can serve the same roles as { and to replace the role of } we just have a new "end" keyword:

Code: [Select]

proc initialize (count)

   if (a = 23)
      a = 0
   end

   if (a = 55)
      a = 10
   end

   if (a > 1024)
      a = 0
      call reset(100)
   end

   if (a < 2048)
      a = 50
      call restart(0)
   else
      a = 1024
   end

   while (state = READY)
        call refresh_display(250)
        state = get_state()
   end

end


PL/I used do; and end; for { and }, the braces are an improvement, much less text but being able to eliminate the braces altogether seems very appealing, it works fine in Julia.

Here's someone's blog post I stumbled upon when reading about Julia, all about this subject The Case Against Curly Braces {} Languages.

[SiliconWizard]

Such thinking is very superficial. Again, the number of keystrokes needed is unimportant. Having to type something explicitly is a "problem" only for total beginners, who think majority of time spent in programming is hitting the keys.

Oh yeah, I keep saying this too.
Focusing on code compactness if futile and unfortunately an obsession not only for beginners. It seems very widespread. Of course, it's much easier to tackle than the more fundamental and more important concepts, which is inherently hard.

The average "productivity" of a software developer is commonly considered about 100 lines of code per day. That means code that is meeting the requirements, fully debugged and tested. Typing 100 lines of code takes only a few minutes for someone with normal typing skills. Clearly this is an absolutely minor fraction of the time spent on developing software.

Time spent on fixing bugs coming from ambiguous code statements / ill-understood implicit language behaviors is, in comparison, gigantic.

[pcprogrammer]

Code: [Select]

  if(a == b)
    c = 10
  end

Is basically just as much typing as

Code: [Select]

  if(a == b)
  {
    c = 10;
  }

I myself like the braces. Wish they had used them in verilog in the same way instead of the begin and end... statements. But that comes down to what one is used to.

And frankly this is all cosmetics, nothing to do with improving functionality of a programming language. So I agree with SiliconWizard that it is futile.

[brucehoult]

Code: [Select]

  if(a == b)
    c = 10
  end

Is basically just as much typing as

Code: [Select]

  if(a == b)
  {
    c = 10;
  }

I myself like the braces. Wish they had used them in verilog in the same way instead of the begin and end... statements. But that comes down to what one is used to.

I like "end" better, if only because it makes for tidier syntax for signalling what is is you are ending, in a way that the compiler can check (i.e. not just a comment).

Code: [Select]

  line:
  while (myLine = readLine())
    :
    if (...) next line;
    :
    if (...) last line;
    :
  end while line

On the "end" statement, either the "while" or the label can be omitted: "end", "end while", "end line".

Obviously for C/Java it is continue/break not next/last but I quite like that Perl idea.

[pcprogrammer]

I like "end" better, if only because it makes for tidier syntax for signalling what is is you are ending, in a way that the compiler can check (i.e. not just a comment).

........

On the "end" statement, either the "while" or the label can be omitted: "end", "end while", "end line".

I see your point, but then it should be done like in verilog where it uses the type within the end, like endcase and endmodule. Only it is not completely consistent because for instance an if uses plain begin / end to mark the block of code.

And to ensure maintained readability it should not be optional. So single line if statements should still end with an endif. On the other hand, the loose rules of C are very nice, but can result in code that is very hard to read.

It all boils down to personal preference

[Mechatrommer]

what is better than Basic? in term of cosmetic and human most friendly and sensible syntax?

Code: [Select]

If (a = b) Then
    c = 10
End If
the problem with it is it doenst support pointer and true OOP.. if Basic can do whatever C can, i think i've left C behind too long time ago...

[Siwastaja]

Code: [Select]

If (a = b) Then
    c = 10
End If


That hurts my (somewhat pedantic and logical) eye because the same operator (=) is used for two different purposes. I don't mind using = as comparison operator, but then something else is needed for assignment, such as :=, or, borrowing from mathematics, "let c = 10".

[Sherlock Holmes]

Code: [Select]

  if(a == b)
    c = 10
  end

Is basically just as much typing as

Code: [Select]

  if(a == b)
  {
    c = 10;
  }

I myself like the braces. Wish they had used them in verilog in the same way instead of the begin and end... statements. But that comes down to what one is used to.

And frankly this is all cosmetics, nothing to do with improving functionality of a programming language. So I agree with SiliconWizard that it is futile.

I understand you, I used PL/I for years and that used do; and end; (with optional labels like Bruce was describing) and I when I began to use C in earnest, appreciated the simplicity and elegance of that. So until literally a couple days ago I was pleased to try and define a grammar that's a hybrid of PL/I with some stuff from other languages including the braces from C.

I've looked at quite a few other language grammars recently, and discovered that Python (like F#) regards indentation as having syntactic meaning, that's kind of interesting but frankly the ease with which valid code can chance behavior/meaning just by a copy/paste error (spaces/tabs unexpectedly creeping in and out), is too large IMHO.

Now that could be made to work in principle, if one could encode the number of spaces inside the line's text using non-displayable Unicode or something, but it wouldn't fly really without special editing tools.

Then I came across Julia and noticed that it is a pretty respected language, truly interesting and novel. Like Python its a "dynamic" language but it is a different beast altogether.

I'd never thought about this before but one can use a keyword statement's keyword to designate the start of a "block" and then require simply an "end" to close it. In PL/I we do use the keyword but only if its part of what they call a "do group" (basically do-group means something than can represent a block, like "do while" and "do until" and "if X then do;" etc.). Pascal is similar with it's reliance on "begin".

But Julia just uses the keyword alone (OK this requires and end always) which in the cold light of day is pretty intelligent of them - IMHO. Then of course Julia also dispenses with semicolons as statement terminators, that puzzled me at first but I can see now that it is quite legitimate to do that.

You say "it is all cosmetic" but decisions to need to be made, one cannot have an informally defined grammar, so one must make decisions if one is considering designing a new language. You can't say "don't change that" because what is that relative too? I'm discussing a new language not changing an existing one! Even if one copies or largely borrows another grammar one must still choose which!

You also say "improving functionality of a programming language" but I am not doing that ! I'm looking at how a brand new language will look, and decisions about block structuring, keywords, statement syntax - (i.e. grammar!) must be made.

[Sherlock Holmes]

Code: [Select]

If (a = b) Then
    c = 10
End If


That hurts my (somewhat pedantic and logical) eye because the same operator (=) is used for two different purposes. I don't mind using = as comparison operator, but then something else is needed for assignment, such as :=, or, borrowing from mathematics, "let c = 10".

I understand you, but allowing and assignment to also be an expression is illegal, meaningless in many programming languages. Derivatives of C do it because, well, because they're derivatives of C! It is in fact one of my biggest complaints about these languages actually.

So unless one has only ever used C-like languages, the code:

Code: [Select]


If (a = b)
    c = 10
end


Will look completely run of the mill, no confusion whatsoever. If one does - as you said - object to the same symbol being used then yes it is the assignment symbol that should be different not the equality symbol, no mathematician would ever tolerate :

a = a + 10

for example, because it is untrue, a provably false proposition. So a purist could argue for a notation more like:

Code: [Select]


If (a = b)
    c <= 10
end


And then "=" is always part of an expression just as its ">" or "<" leading to improved symmetry.

I've been thinking about this in fact but have leaned towards the fact that "=" for assignment is so ubiquitous, like, almost all languages have adopted that, but it should be considered, perhaps another symbol is the right thing to do...

[Mechatrommer]

Code: [Select]

If (a = b) Then
    c = 10
End If


That hurts my (somewhat pedantic and logical) eye because the same operator (=) is used for two different purposes. I don't mind using = as comparison operator, but then something else is needed for assignment, such as :=, or, borrowing from mathematics, "let c = 10".

we are aware of this, but the compiler is clever enough to know when to assign and when to compare. it also happen to us human, there is difference when we say "a equals b" and "if a equals b", thats why i said, language is too subjective. if you want to impose technically and grammatically correct syntax in communication, good luck!.

I understand you, but allowing and assignment to also be an expression is illegal, meaningless in many programming languages.

try to make your language same popularity with Basic at best... even though its grammatically incorrect, it can make good programs. proven millions time.

[Sherlock Holmes]

Something else to consider in a language aimed at improving how we write code for MCUs, is the inclusion of operators for:

1. Arithmetic shifting
2. Logical shifting
3. Rotation
4. NAND
5. NOR

Some of these are available in some languages as core operators, but I don't think any language covers all of the possibilities (with the exception of assembler).

[rstofer]

Pascal uses := for assignment and = for comparison.  It took about 5 minutes to get used to this notation.  I rather like it...