ℙ𝕖𝕡 🙴 ℕ𝕠𝕞

6 apr 2025

Smart is the dumb person's word for intelligent Seinfeld

where are we going?

I have been continuing to work on different aspects of the ℙ𝕖𝕡 🙵 ℕ𝕠𝕞 system including this website and also on the translation scripts in the /tr/ folder. I keep a record of mundane work carried out on the system at /doc/pepnom.doc.journal.html . The new translation scripts will be called for example /tr/nom.todart.pss . At the moment only the new dart translation script is working well.

The nom language and pep machine continues to demonstrate (to me, at least) it’s power and simplicity and facility of use. I feel like it needs some kind of “influential” sponsor. Somebody who can see it’s qualities and help in it’s development. The writing of compilers seems to be considered “difficult” or abstruse but the grammatical principles are really not that hard to grasp.

The go compiler is fast and seems to produce fast code. I believe it was mainly designed and probably implemented by Rob Pike and his team at google. These are definitely people who know what they are doing. But I find it strange or curious that the following code will not compile.

   package main
   import "fmt"
   func main() {
       if 1 == 0 { fmt.Println("True is false") }
       else { fmt.Println("No it is not") }
   }
 

What is the problem here? Its pretty simple and mundane and not really of any earth-shattering importance: The venerable else keyword is on a new line after the closing brace of the if clause. Plenty of languages allow you to put the “else” on the next line but not GO .

Does it matter? Not really. The street children of Mumbai are not going to all find loving homes just because we can put an else keyword on the next line. The deforestation of the Australian and Amazonian forests is not in any way affected by this situation. But it is still curious.

Why am I even writing about this? The reason is, that I think that it shows that the tools that even luminaries like Mr Pike use to write compilers are perhaps not very good. I suspect that everybody is still just writing recursive-descent parsers ( Bob Nystrom of Dart fame, seems to think so). I also suspect that people are still just doing line-by-line tokenisation. Now, I am sure that the golang team could have made a more flexible parser for go, but it probably wasn't a big priority. They probably weren't overly interested. They probably just wanted a fast, simple, easy-to-understand parser that works. And it does.

But this could be a symptom of a bigger problem: that parser/compiler writers don’t really enjoy the grammatical process. They find it hard to think about, and they would rather be thinking about other algorithmic problems. Obviously I am doing a lot speculation here, and I have not inspected the golang compiler, mainly because looking at recursive descent parsers written in c or c++ or go is not my idea of intellectual recreation.

I have another example for this blog post. Why did somebody as knowledgable as Niklaus Wirth think that it was necessary to end a program block with a semicolon or a dot? What is wrong with the end keyword. Is it not endy enough? How many ends do you need?

   y:=10;
   if x>1 then
   begin
     x:=1;
     y:=y-1;
   end;
   while y>1 do
   begin
     inc(x);
     dec(y);
   end;
 

Once again, I suspect that this has to do with recursive-descent parsing and maybe a lack of understanding of grammar. Or perhaps it is just a desire to avoid the necessity for parse token lookahead*. I don’t think that the en.wikipedia.org/wiki/dangling_else problem is an excuse in this case. But, once again, it seems like these pioneers of language parsing and compiler writing did not have good simple tools and their disposal for parsing and translating languages. Or maybe I am wrong.

May I humbly suggest ℕ𝕠𝕞 as an interesting and simple text tool for working with recognisers/parsers/translators/transpilers and maybe even compilers.