The Imperium programming language - IPL

[brucehoult]

The fun part is that the thread is starting to look like a popularity contest (which is what ends up happening in many programming language threads anyway) rather than stick to purely technical points. Which usually means game over, but I don't wanna ruin the thread. Good luck!

That happened long ago. The thread OP is still, as of yesterday, hurling personal abuse and insults at those who disagree with HIS pet ideas.

[Brianf]

What was PL/M like, and should it come back?  I've never used it.

As it looks like I'm the only one here who has used PL/M (for about 3 years) I'd put is somewhere between C and assembler. I still have a bit of a soft spot for it and would happily use it if a compiler were available. 

I read above that PL/M is a stripped back PL/I. Having never looked at any PL/I source code until today I can see a vague passing resemblance but that might be the all-caps text fooling me.

[Mechatrommer]

if i'm going to make a new language, it will be somewhere between Basic and C... and then we have 16 competing standards...

[Sherlock Holmes]

What was PL/M like, and should it come back?  I've never used it.

As it looks like I'm the only one here who has used PL/M (for about 3 years) I'd put is somewhere between C and assembler. I still have a bit of a soft spot for it and would happily use it if a compiler were available.

I read above that PL/M is a stripped back PL/I. Having never looked at any PL/I source code until today I can see a vague passing resemblance but that might be the all-caps text fooling me.

I never used PL/M myself but have been looking at it closely recently, it was - at least initially - closely allied with the 8080, the language itself had facilities for interacting with DMA devices too it seems, may I ask, what kind of work did you do with PL/M?

PL/I was a designed, specified programming language. It was created after a detailed analysis of assembler, Cobol, Algol and Fortran. It had rich bit and packing/alignment features due to the cost of memory. Many programmers back then (1960s) had solid assembler experience and were no strangers to packing data into fields to conserve memory, so it was high on the list of the designers to give the PL/I programmer a similar ability to work at that level, this are received a lot of attention - all these years later that same mindset could apply to resource constrained MCUs.

It was a huge success and saw huge uptake in UK and Europe as well as Eastern block countries, it was marketed there differently to the US, where the costs of the language were rather high and this perhaps the biggest reason it became less well known over here. My first real programming job was a trainee programmer on PL/I on IBM mainframes in Enfield, London. Later I was hired to work in the City of London because Stratus hardware fault tolerant computer had started to see like hot cakes in mission critical environments (stock exchanges, investment banks, market makers). Stratus was interesting and had an OS written in PL/I subset G and was the preferred language to use on these machines, PL/I programmers were thus in demand and I got a job on that basis. The CTO of Stratus was interesting too, had a business developing and selling compilers (including PL/I) for Burroughs, DEC, Data General, Prime etc.

For those interested in computer history here's an interview with him.

I've been particularly concerned recently with the grammar for a new language, once a grammar is defined there's no going back, one must live with the consequences of the choice for the lifetime of the language, PL/I's grammar is not perfect but it is perhaps one of the best imperative language grammars around IMHO.

I also developed a Subset G PL/I compiler during the 90s so I have solid experience of this, that compiler was never strictly completed but did generate linkable runnable COFF object modules for Windows NT, I wrote the entire compiler (except the small bootstrap start code which was assembler) in C, initially Borland then later Visual C, writing a compiler for PL/I in C was a unique learning experience, I saw the good. the bad and the ugly of both languages, up close, this was all before the internet too, so all research and design was driven by books and histiorical reprints of articles and papers from my local library.

[rstofer]

PL/M source code here:

http://www.cpm.z80.de/source.html

It is written in Fortran 66.

[Sherlock Holmes]

PL/M source code here:

http://www.cpm.z80.de/source.html

It is written in Fortran 66.

That's pretty interesting, I've never see Fortran up close, also the PL/M to C translators written in C is intriguing too, thanks for posting that.

[Brianf]

What was PL/M like, and should it come back?  I've never used it.

As it looks like I'm the only one here who has used PL/M (for about 3 years) I'd put is somewhere between C and assembler. I still have a bit of a soft spot for it and would happily use it if a compiler were available.

I read above that PL/M is a stripped back PL/I. Having never looked at any PL/I source code until today I can see a vague passing resemblance but that might be the all-caps text fooling me.

I never used PL/M myself but have been looking at it closely recently, it was - at least initially - closely allied with the 8080, the language itself had facilities for interacting with DMA devices too it seems, may I ask, what kind of work did you do with PL/M?

We were doing remote control and monitoring of industrial equipment.

8085 processor, 8259 interrupt controllers, 8237 DMA controllers, 8251 UARTs, 8274 HDLC/SDLC controllers, plus RAM and EPROM on the processor board. The 8251s talked in/out to multiple serial ports. The 8274 implemented an 800kbps interboard comms link. All running under DMA to reduce CPU usage.

8031 processor (don't ask) and a TMS9918 (?) VDP on the graphics board, commands via a 8274 on the interboard comms link. Also using PL/M (PL/M-51).

8751 (old top, UV window) in the remote units with analogue inputs, digital outputs via relays, and digital inputs.

[Sherlock Holmes]

What was PL/M like, and should it come back?  I've never used it.

As it looks like I'm the only one here who has used PL/M (for about 3 years) I'd put is somewhere between C and assembler. I still have a bit of a soft spot for it and would happily use it if a compiler were available.

I read above that PL/M is a stripped back PL/I. Having never looked at any PL/I source code until today I can see a vague passing resemblance but that might be the all-caps text fooling me.

I never used PL/M myself but have been looking at it closely recently, it was - at least initially - closely allied with the 8080, the language itself had facilities for interacting with DMA devices too it seems, may I ask, what kind of work did you do with PL/M?

We were doing remote control and monitoring of industrial equipment.

8085 processor, 8259 interrupt controllers, 8237 DMA controllers, 8251 UARTs, 8274 HDLC/SDLC controllers, plus RAM and EPROM on the processor board. The 8251s talked in/out to multiple serial ports. The 8274 implemented an 800kbps interboard comms link. All running under DMA to reduce CPU usage.

8031 processor (don't ask) and a TMS9918 (?) VDP on the graphics board, commands via a 8274 on the interboard comms link. Also using PL/M (PL/M-51).

8751 (old top, UV window) in the remote units with analogue inputs, digital outputs via relays, and digital inputs.

Wow, OK so hardly some trivial system, I found the exact manual here.

Seems PL/M (unlike PL/I) does reserve its keywords.

[Brianf]

And then there's the book...

https://www.amazon.co.uk/Guide-P-Programming-Microcomputer-Applications/dp/0201045753/

[Sherlock Holmes]

The fun part is that the thread is starting to look like a popularity contest (which is what ends up happening in many programming language threads anyway) rather than stick to purely technical points. Which usually means game over, but I don't wanna ruin the thread. Good luck!

It seems you are a French speaker, so on that basis let me ask you a question, how would you update this JSON's "fr" entry to use the most appropriate French terms for the various keywords:

{
  "en": {
    "IsNotAKeyword": "0",
    "Argument": "argument",
    "Binary": "binary",
    "Boolean": "boolean",
    "Builtin": "builtin",
    "By": "by",
    "Call": "call",
    "Coroutine": "coroutine",
    "Decimal": "decimal",
    "Declare": "declare",
    "End": "end",
    "Enum": "enum",
    "Fixed": "fixed",
    "Float": "float",
    "Function": "function",
    "Goto": "goto",
    "If": "if",
    "Internal": "internal",
    "Interrupt": "interrupt",
    "Language": "lingua",
    "Loop": "loop",
    "Namespace": "namespace",
    "Out": "out",
    "Private": "private",
    "Procedure": "procedure",
    "Public": "public",
    "Readonly": "readonly",
    "Ref": "ref",
    "Return": "return",
    "Returnon": "returnon",
    "Singlet": "singlet",
    "Static": "static",
    "String": "string",
    "Structure": "structure",
    "To": "to",
    "Type": "type",
    "Until": "until",
    "Using": "using",
    "While": "while",
    "Varying": "varying",
    "Yield": "yield",
    "Arg": "arg",
    "Bin": "bin",
    "Dcl": "dcl",
    "Dec": "dec",
    "Func": "func",
    "Proc": "proc",
    "Struct": "struct"
  },

  "fr": {
    "IsNotAKeyword": "0",
    "Argument": "argument",
    "Binary": "binaire",
    "Boolean": "booléenne",
    "Builtin": "intégré",
    "By": "by",
    "Call": "appeler",
    "Coroutine": "coroutine",
    "Decimal": "décimal",
    "Declare": "déclarer",
    "End": "fin",
    "Enum": "enum",
    "Fixed": "fixe",
    "Float": "flottant",
    "Function": "fonction",
    "Goto": "goto",
    "If": "si",
    "Internal": "interne",
    "Interrupt": "interrompre",
    "Language": "lingua",
    "Loop": "boucle",
    "Namespace": "namespace",
    "Out": "depuis",
    "Private": "privé",
    "Procedure": "procédé",
    "Public": "public",
    "Readonly": "readonly",
    "Ref": "ref",
    "Return": "retour",
    "Returnon": "retour si",
    "Singlet": "singlet",
    "Static": "static",
    "String": "chaîne",
    "Structure": "structure",
    "To": "to",
    "Type": "type",
    "Until": "avant",
    "Using": "using",
    "While": "tandis que",
    "Varying": "varying",
    "Yield": "donner",
    "Arg": "arg",
    "Bin": "bin",
    "Dcl": "dcl",
    "Dec": "déc",
    "Func": "fonc",
    "Proc": "proc",
    "Struct": "struct"
  }

The current terms are very crude, looked up hastily and no doubt poorly, my Wife speaks French like a native (she studied linguistics and majored in French) but she's not familiar with technology or the intent of these various keywords.

The lexical analyzer and parser has no problem handling keywords with multiple terms either like "go to" (EN, Goto) or "tandis que" (FR, While) or "retour si" (FR, ReturnOn) etc, accent characters are fine too.

[tggzzz]

What was PL/M like, and should it come back?  I've never used it.

As it looks like I'm the only one here who has used PL/M (for about 3 years) I'd put is somewhere between C and assembler. I still have a bit of a soft spot for it and would happily use it if a compiler were available.

I read above that PL/M is a stripped back PL/I. Having never looked at any PL/I source code until today I can see a vague passing resemblance but that might be the all-caps text fooling me.

I never used PL/M myself but have been looking at it closely recently, it was - at least initially - closely allied with the 8080, the language itself had facilities for interacting with DMA devices too it seems, may I ask, what kind of work did you do with PL/M?

PL/I was a designed, specified programming language. It was created after a detailed analysis of assembler, Cobol, Algol and Fortran. It had rich bit and packing/alignment features due to the cost of memory. Many programmers back then (1960s) had solid assembler experience and were no strangers to packing data into fields to conserve memory, so it was high on the list of the designers to give the PL/I programmer a similar ability to work at that level, this are received a lot of attention - all these years later that same mindset could apply to resource constrained MCUs.

It was a huge success and saw huge uptake in UK and Europe as well as Eastern block countries, it was marketed there differently to the US, where the costs of the language were rather high and this perhaps the biggest reason it became less well known over here. My first real programming job was a trainee programmer on PL/I on IBM mainframes in Enfield, London. Later I was hired to work in the City of London because Stratus hardware fault tolerant computer had started to see like hot cakes in mission critical environments (stock exchanges, investment banks, market makers). Stratus was interesting and had an OS written in PL/I subset G and was the preferred language to use on these machines, PL/I programmers were thus in demand and I got a job on that basis. The CTO of Stratus was interesting too, had a business developing and selling compilers (including PL/I) for Burroughs, DEC, Data General, Prime etc.

For those interested in computer history here's an interview with him.

I've been particularly concerned recently with the grammar for a new language, once a grammar is defined there's no going back, one must live with the consequences of the choice for the lifetime of the language, PL/I's grammar is not perfect but it is perhaps one of the best imperative language grammars around IMHO.

I also developed a Subset G PL/I compiler during the 90s so I have solid experience of this, that compiler was never strictly completed but did generate linkable runnable COFF object modules for Windows NT, I wrote the entire compiler (except the small bootstrap start code which was assembler) in C, initially Borland then later Visual C, writing a compiler for PL/I in C was a unique learning experience, I saw the good. the bad and the ugly of both languages, up close, this was all before the internet too, so all research and design was driven by books and histiorical reprints of articles and papers from my local library.

If you are interested in PL/M, you ought to understand Coral-66 (that's 1966). Key points emphasised...

Coral 66 is a general-purpose programming language based on ALGOL 60, with some features from Coral 64, JOVIAL, and FORTRAN. It includes structured record types (as in Pascal) and supports the packing of data into limited storage (also as in Pascal). Like Edinburgh IMP it allows embedded assembler, and also offers good run-time checking and diagnostics. It is specifically intended for real-time and embedded applications and for use on computers with limited processing power, including those limited to fixed point arithmetic and those without support for dynamic storage allocation.
The language was an inter-service standard for British military programming, and was also widely adopted for civil purposes in the British control and automation industry. It was used to write software for both the Ferranti [2] and GEC computers from 1971 onwards. Implementations also exist for the Interdata 8/32, PDP-11, VAX, Alpha platforms and HP Integrity servers; for the Honeywell, and for the Computer Technology Limited (CTL, later ITL) Modular-1; [3] as well as for SPARC running Solaris and Intel running Linux.
A variant of Coral 66 was developed during the late 1970s/early 1980s by the British GPO, in conjunction with GEC, STC and Plessey, for use on the System X digital telephone exchange control computers, known as PO-CORAL. This was later renamed BT-CORAL when British Telecom was spun off from the Post Office. Unique features of this language were the focus on real-time execution, message processing, limits on statement execution between waiting for input, and a prohibition on recursion to remove the need for a stack.
As Coral was aimed at a variety of real-time work, rather than general office DP, there was no standardised equivalent to a stdio library. IECCA recommended a primitive I/O package to accompany any compiler (in a document titled Input/Output of Character data in Coral 66 Utility Programs). Most implementers avoided this by producing Coral interfaces to existing Fortran and, later, C libraries.
Perhaps CORAL's most significant contribution to computing was the enforcement of quality control in commercial compilers. [3] To have a CORAL compiler approved by IECCA, and thus allowing a compiler to be marketed as a CORAL 66 compiler, the candidate compiler had to compile and execute an official suite of 25 test programs and 6 benchmark programs. The process was part of the BS 5905 approval process. This methodology was observed and adapted later by the United States Department of Defense for the official certification of Ada compilers.

IIRC it included a fixed point data type, with associated arithmetic operations.

[Sherlock Holmes]

So lets talk about structures.

Several important aspects to this area are:

1. Runtime ordering of member fields
2. Alignment of member fields
3. Padding between member fields
4. Packing

The runtime ordering (that is order of fields when ordered by offset from start of structure) is fixed in C and C++, one must manually adjust the lexical order to effect a change to the runtime order.

So this suggest something like:

Code: [Select]


def header struct order (auto)
   ...
end

def header struct order (explicit)
   ...
end


With some default when "order" is omitted. The "auto" meaning to let the compiler order the members my decreasing alignment needs.

Alignments could be specified at the structure level, or perhaps at the member level too.

Padding is a function of alignment I suppose, so is implicit or could be instead of:

Code: [Select]


def header struct
   length bin(16)
   code byte(1)
   padding(1)
   type bin(32)
end

or

Code: [Select]

def header struct aligned
   length bin(16)
   code byte(1)
   type bin(16)
end


Specifying "aligned" means you cant also specify any padding and vice versa. The "padding" keyword can appear many times inside a structure definition and basically forces the offset of following fields, so "padding" would prevent "order(auto)" since it's antagonistic to that.

One could also have "unused(n)" as well as "padding(n)". In that case an "unused" allocates real space but it can't be accessed, if it is, the compiler can report an error. That means we can cater for fields that are present and might be aligned poorly, but we don't care because we will never access that field.

One should be able to devise a set of keywords and options that give huge control over all aspects of structure's memory layout like this, meaning one can meet any conceivable need.

Thoughts?

[SiliconWizard]

Alignment and packing can be defined in many programming languages these days. Even C. This is certainly useful but nothing new. Ada is by far the most flexible for this.
Automatic ordering of members is rarer - well, some languages do not define a specific order for "structures", so compilers are allowed to reorder the members as they see fit. Not particularly new either, but indeed not in C or C++. While not mind-blowingly useful, that would give opportunities for optimizations when the developer doesn't care about order, which is relatively frequent indeed unless you map structs to low-level objects.

[Sherlock Holmes]

Alignment and packing can be defined in many programming languages these days. Even C. This is certainly useful but nothing new. Ada is by far the most flexible for this.
Automatic ordering of members is rarer - well, some languages do not define a specific order for "structures", so compilers are allowed to reorder the members as they see fit. Not particularly new either, but indeed not in C or C++. While not mind-blowingly useful, that would give opportunities for optimizations when the developer doesn't care about order, which is relatively frequent indeed unless you map structs to low-level objects.

Yes, I know this is nothing new, the language is new but not the underlying concepts.

I'm leaning toward this now as the way to declare structures/types and explicitly include padding and unused regions:

Code: [Select]


def message struct
    sequence bin(31)
    tag      byte(2)

    // Note all members that are padding/ignored must have same name within the struct

    XXXX    byte (5) padding
    XXXX    byte (3) ignored // ignore the 3 byte checksum
end


This seems neat to me, how many times have we had to declare unused fields in complex structures and been forced to name them "ignore_1" and "ignore_2" and so on? I have and it's these kind of things that interest me with a new language.

So here you can use any name you want for a "padding" or "ignored" field but with the proviso that every such field within a struct/type must use the very same name, look at the example, I chose XXXX and look how easy it is to visually scan and see that name repeated, it's clear they are either ignored or padding, very helpful when scanning visually over potentially complex code...

This is trivial for a good parser and also very rational, since you can't ever refer to an ignored field or a padding field, there's no reason for them not to have the same name! The name is only a means to and end anyway, a means by which the code generation phase can determine the address being referred to.

[SiliconWizard]

The fun part is that the thread is starting to look like a popularity contest (which is what ends up happening in many programming language threads anyway) rather than stick to purely technical points. Which usually means game over, but I don't wanna ruin the thread. Good luck!

It seems you are a French speaker, so on that basis let me ask you a question, how would you update this JSON's "fr" entry to use the most appropriate French terms for the various keywords:
(...)

I missed this thread which is why I didn't answer. Note that I don't think translating programming language keywords is ever a good idea (it has been done before, and it eventually died.)
But anyway, I'll have a look at the list if I get the time.

[Sherlock Holmes]

The fun part is that the thread is starting to look like a popularity contest (which is what ends up happening in many programming language threads anyway) rather than stick to purely technical points. Which usually means game over, but I don't wanna ruin the thread. Good luck!

It seems you are a French speaker, so on that basis let me ask you a question, how would you update this JSON's "fr" entry to use the most appropriate French terms for the various keywords:
(...)

I missed this thread which is why I didn't answer. Note that I don't think translating programming language keywords is ever a good idea (it has been done before, and it eventually died.)
But anyway, I'll have a look at the list if I get the time.

Very well, but to infer it is never a good idea is something of a stretch surely? The case here though is that the ability to freely and reliably support keywords from other languages is an unanticipated consequence of the grammar's lack of reserved words. Because of that it is almost a no brainer so is something I'd leverage as low hanging fruit.

All we have to do is change every keyword to say French or Dutch and then add/change the language directive and we're done. I already played around with this and the language code (like "en" or "fr") is now an argument to the lexical analyzer.

Even better, one could alter the language instantly within an IDE or editor without to much effort, a syntax aware editor could do that, just parse the code, and replace every keyword in the parse tree with its French, German etc, equivalent and you're done.

I've been looking at Antlr4 as a possible means to more formally develop the grammar but I don't yet know if it is capable of handling some of the grammar needs, I'm chatting to Antlr people to try and get clarity.

Anyway, thanks for taking a look.

[Sherlock Holmes]

I've been doing more investigation into features that might be helpful with a new language. One of these (again) comes right from PL/I.

That language supports "pointer" as a data type but it also support another related data type "offset".

That's right, you can declare structure members as "offset" and that means the runtime address of the datum is relative to some base address. This means one can create fully relocatable linked data structures, so long as the base address is established the data structure "works" fine.

This is closely associated with PL/I's "area" support, effectively user declared heaps. You can declare a "heap" and allocate and free within that heap, then later you can (if you wanted to) copy the area or persist and so on, and later reload the area into memory and the data structures in there, linked lists, two way lists, trees etc will function perfectly (if offsets are used rather than pointers).

Anyway these are ideas that might have some utility in an MCU setting.

[DavidAlfa]

[MIS42N]

    No reserved words, thus enabling new keywords to be added over time.
NO - learning a language has a lot to do with knowing the reserved words and what they do. How do you give a program to another person to maintain if you've cooked up your own set of names. If a future conflict with a new reserved word, that's what global find and replace does well. I quite often write code with labels like X57 then come back and do a replace later with something more meaningful. It saves time if labels are short to type. A global search and replace finds labels that have no other reference, so asks the question, did I forget something.

    Support 'bit' as a native data type.
YES - I think COBOL has had this for quite a while with USAGE BIT and PIC 99 COMP etc. By specifying exactly what you want, it's up to the compiler to figure it out - big endian, little endian etc.

    Support 'strings' as a native type, BCD/decimal as well.
YES - as above

    Support for namespaces.
Some sort of name scope is useful.

    Computed gotos.
YES

    Flexible alignment, packing and padding directives.
? - maybe. Shouldn't the compiler handle this anyway, that's what they are there for.

    Nested functions.
This is for small microcontrollers? could get messy.

    Precision timing features like emit multiple NOP operations or ensure identical execution time for (say) case clauses in a switch.
    Support for an async/await model.
I would prefer not to hand these to a compiler.

I tried to come to grips with the PIC XC8 compiler but getting it to play nicely with my assembler was exhausting and the code was incomprehensible. So back to all assembler. A good library of assembler sources that can be cut and pasted are very useful. Add plenty of documentation, I find it easier than just about any other language that isn't well documented. And I know exactly what is going on. Using a higher level language rarely produces optimal code. Perhaps one day an AI can be trained by reading a couple of million lines of C (or whatever) code and the hand coded assembler to do the same thing. Then I might use it.

Regarding which, the newer PIC16 architecture fixes many of the problems with the older architecture. It now has arithmetic with carry (which just about every other processor had for ever). Two 16 bit index registers that can access data and program memory with pre/post indexing or offsets. Data memory can be accessed via the page method or as a linear space. Interrupts save (and RETFIE restores) the most significant registers (8 bytes) in a single instruction cycle. And part of addressable 'data' memory gives access to the call/return stack and the saved registers in an interrupt. Some of the peripherals are enhanced too - timer 1 and the PWM can use the base clock (up to 64MHz) instead of the instruction clock (base/4).

Somewhat off topic.

[SiliconWizard]

I would make the following changes: (only kept what needs changed here)

  "fr": {
   
    "Boolean": "booléen", -- more neutral form, 'booléenne' is the feminine version, although feminazis may not like the neutral form, which is masculine

    "Builtin": "intégré", -- this one doesn't sound quite right to me (even if the general meaning is correct), but I don't really know how to translate it better without more context about what 'builtin' would mean in said prog. language

    "By": "par",

    "Goto": "aller à/en",

    "Interrupt": "interruption",

    "Language": "langage",

    "Namespace": "espace de noms", -- which is correct but frankly looks odd and overly verbose

    "Out": "sortie",

    "Procedure": "procédure",

    "Readonly": "lecture seule",

    "Singlet": "singleton", -- if by 'singlet' you mean a set or list of 1 element

    "Static": "statique",

    "To": "à",

    "Until": "jusqu'à ce que",

    "Using": "utilisant",

    "While": "tant que",

    "Varying": "variant",

    "Yield": "céder",

  }

Some keywords are clunky to translate, and I don't think it's a good idea as I said (and MIS42N said as well.) But there you go.

[Sherlock Holmes]

I would make the following changes: (only kept what needs changed here)

  "fr": {
   
    "Boolean": "booléen", -- more neutral form, 'booléenne' is the feminine version, although feminazis may not like the neutral form, which is masculine

    "Builtin": "intégré", -- this one doesn't sound quite right to me (even if the general meaning is correct), but I don't really know how to translate it better without more context about what 'builtin' would mean in said prog. language

    "By": "par",

    "Goto": "aller à/en",

    "Interrupt": "interruption",

    "Language": "langage",

    "Namespace": "espace de noms", -- which is correct but frankly looks odd and overly verbose

    "Out": "sortie",

    "Procedure": "procédure",

    "Readonly": "lecture seule",

    "Singlet": "singleton", -- if by 'singlet' you mean a set or list of 1 element

    "Static": "statique",

    "To": "à",

    "Until": "jusqu'à ce que",

    "Using": "utilisant",

    "While": "tant que",

    "Varying": "variant",

    "Yield": "céder",

  }

Some keywords are clunky to translate, and I don't think it's a good idea as I said (and MIS42N said as well.) But there you go.

Much appreciated. The language support is easy to implement as an option, like a "pragma" in C. Not used unless someone wants it. English will be default. There's little cost in doing it, low hanging fruit.

[JPortici]

Do you know how much i hate that i have to translate excel/calc functions because one colleague's pc is set to italian locale and my pc is set to english locale?
Translatable keywords is as bas as no reserved words

And there is nothing bad in having reserved words, even if they are not in your native language. I remember it took me a time to understand why word "x" was chosen. After all in middle school we were learning programming alongside english. But it didn't really matter. I only knew i had to follow the syntax

[Sherlock Holmes]

Do you know how much i hate that i have to translate excel/calc functions because one colleague's pc is set to italian locale and my pc is set to english locale?
Translatable keywords is as bas as no reserved words

And there is nothing bad in having reserved words, even if they are not in your native language. I remember it took me a time to understand why word "x" was chosen. After all in middle school we were learning programming alongside english. But it didn't really matter. I only knew i had to follow the syntax

Say you use a new language, develop some significant software, important to you, your company. Assume the version 1.0 of the language you used had no keyword "async". Assume further, one of the developers liked the word and used it for say a function name, all good.

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)?

[JPortici]

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

[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

I think in C compilers we can do some on a per function basis, but not on the file scope