theletterf/english-lang

The English Programming Language

english-lang's Issues

The JIT compiler may not work properly in some countries

It's a hard language to become senior if you are using just a computer or smartphone. At least you will need use pair programming to aims this seniority.
The interpreter can run extremily slow if the streamming of data comming in high baud rate though commoly layer network. It run better on native hardware.

Missed opportunity for punny punctuation

The "Syntax" section states:
Statements can end with a period or, less frequently, with a semicolon. Blocks are usually separated by two or more line breaks.

Clearly, it should instead read:
...Statements can end with a period or, less frequently, with a semicolon; blocks are usually separated by two or more line breaks.

Add borrow checker and memory safety

As of 2024, the Whitehouse mandates that all languages used in new projects must be safe.

I tried using this English Language for a small network construction task in the home lab, but when I dropped the hammer on my toe, I emitted some words from this English Language that were decidedly Unsafe !

Experimenting further - I found that the ease with which I was able to construct entire sentences out of unsafe words was absolutely hair raising.

I really think this language needs to implement a borrow checker, and other pointless / annoying safety “features” if it is to become “highly regarded” on stack overflow surveys, or HN posts.

You can’t just have people construct sentences without some sort of Automated Orwellian Oversight - they could end up saying anything !

Statement does not compile

The statement "Up with this I shall not put!" does not compile. Is there a problem with the parser?

Ambiguous expressions

I'm having trouble with English's non-determinism: I keep hitting expressions that have multiple valid interpretations, and the runtime doesn't always return the same result. It happens infrequently, but consistently.

For example, "Time flies like an arrow" has at least three valid interpretations, each with a different result.

When the runtime hits one of these, it seems to run some kind of ML model to predict the best interpretation based on the program's current state. This works surprisingly well, but the non-determinism is worrying, as is the unexpected complexity and cost.

How much of a breaking change would it be to either mandate a fixed interpretation for all of these ambiguities, or just remove them altogether?

Thanks in advance. I'm loving English otherwise, it's impressively powerful and concise. And so widely supported!

Documentation eratta regarding standards

Standards

...While no standard exists...

There are actually several independent standards, several of which are extraordinarily detailed.

The Chicago Manual of Style

The Associated Press Stylebook

Modern Language Association Handbook

There are some occasional incompatibilities between standards relating to syntax, for instance the AP style book does not utilize the Oxford comma syntax, while the Chicago Manual of style does. Using one when the other is called for can result in parsing errors, therefore it is preferred to stick to one standard.

And regarding:

...English follows a Write Once, Read Anywhere, Then Rewrite (WORATR) philosophy....

It is often said that writing is rewriting, as such I would assert that the English dev environment follows a "write/rewrite, post, and read" paradigm (WRPAR, commonly pronounced 'warper' or 'werper', depending on regional dialects).

I already have a pull request #12 and I could add these as commits if you like...

Best regards,

Andy Somers
Chief Quibbling Officer
Ministry of Prolixity
South Wales, UK

The equality operator (==) behaves like JavaScript. Should we require a ===?

Facing a challenging situation here. There are two statements:

yodaSays = "Named must your fear be, before banish it you can."

myWords = "You must name your fear before banishing it."

yodaSays == myWords  // true

Another such example

yodaSays = "When you look at the dark side, careful you must be. For the dark side looks back."

myHead = "You must be careful when you look at the dark side. For the dark side looks back."

yodaSays == myHead  // true

So, while we're using two different statements, they're equal. While being differently written. So, should there be a === check when talking about checks like this? This might lead to different interpretations in certain cases. 🤔🤔 (Especially comparing between forks.)

Errors and troubleshooting

We need docs on error codes and troubleshooting steps!

Documentation is too terse

One can argue that it takes time to produce good documentation, but why does the only example provided have to be so complex? Why not stick to tried and tested traditions such as

"Hello, World!"
"The book is on the table."
"Nice to meet you."

then move on to more elaborate examples such as

"Peter Piper picked a peck of pickled peppers."
"She sells sea shells by the sea shore."
"Madam, I'm Adam."

Is there any diagram chart to show english-lang programming in practice ?

LLM inference

I have learned some of the language. I would never guessed it is the main core of every LLM.
Impressed 💯. Is there any plan for English lang 2?