Оберон-клуб «ВЄДАsoft»

Thank you for your interest.

I am also following your XDev project with great interest. In my opinion, it has clearly displayed the viability and benefits of the Oberon/Component Pascal family on many platforms, just like the Astrobe compiler of Mr. Chris Burrows. As for my compiler, I didn't intend to make it a full-fledged development tool, but only a demonstration of concept. For many years, I have been searching for a way to cure the bloatware disease that had plagued the whole IT industry all over the world, and now I has found the solution of Niklaus Wirth. So I has written this compiler as a mean of verifying the teachings of Niklaus Wirth.

About myself, my name is Đặng Minh Công and I am Vietnamese. I am just an Informatics (or Computer Science, according to the Anglo-American) student at UET, Hanoi National University of Vietnam. I think it is not a coincident that the Wirthian languages have more followers in Russia and other SNG states than in Western world and Asia. My parents had studied Cybernetics in the Soviet Union during the 70s and I somehow inherited their viewpoints on scientific methods (I was also born in Moscow, but only stayed there for 1 years, so I didn't have the chance to learn the Russian language. I have always wanted to learn Russian, but didn't have time). I believe the Soviet mindset was one of the reason that draw us to Oberon.

In my opinion, the bloatware crisis in IT industry is not origin from the IT industry itself, but has the root in society and the economy. Since 1970s, a neo-liberalism craze had swept all over the world, not even the Soviet Union and the USA were immune from it. Coincidence with it, in the next decades, was the rise of C, UNIX, badly-designed technologies and bloatware. The blame lies on the private enterprises, with their never-ending thirst for profit, they will do anything to compromise the product's quality, in order to raise their profit rate. Many recent airplane accidents were examples of that. And the universities, where many people came to learn and research knowledge, became a place that churned out cheap workforce for the corporations. Until those problems be addressed, I think people who value simplicity and clarity like Niklaus Wirth and us will remain a minority

Sorry for my ranting.

Regards,
Đặng Minh Công

Your article on ZXDev is excellent and here is some suggestions of mine:

Your choice of generating C code instead of native assembly code is totally right. I don't know much about ZX platform but I bet it is a computer architecture belong to 8-bit/16-bit era, and therefore, the need of optimized code is totally necessary. The C compiler had done all the jobs for us, so we don't need to reinvent the wheel. Moreover, interfacing with existing C libraries will be trivial. However, the usage of C language will greatly "simplify" the code generator, and therefore, the compiler writer will be tempted for introducing more "sophisticated extensions". It is a dangerous trap we will need to avoid of. Take a look at vladfolts Oberon-7 compiler, because his compiler generates JavaScript code, he has the freedom to introduce many extensions into Oberon language. In my opinion, many extensions of his are excessive.

As for the problem of unsigned integer, I must say that your tricks are impressive. But in long term, I think you must introduce proper unsigned types. Prof. Wirth had his reason for not using unsigned types, because he is working on machines with several megabytes of memory (and now, several gigabytes). I still remember the days of Turbo Pascal, when the 16-bit INTEGER was too small to do any serious computation.

As for const array extensions, I have a mixed feeling about it. My suggestion is to make a separated CONSTDATA section, so that the syntax of CONST section will be the same as in other Oberon dialects:


About my compiler, I am planning to not making any new features or structural changes, instead, I will focus on bug fixing and making applications with my compiler. By doing that, I can evaluate my compiler quality and the viability of Oberon-07 language.
I think this paper has nailed down the benefits of simplicity: http://smirt23.uk/attachments/SMiRT-23_Paper_103.pdf. With a simple solution, we can quickly apply it in many problems, and therefore, can quickly see its strong and weak points, and then improve it further.

As for permission to publish, feel free to do anything with it. I am not a greedy capitalist, so the idea of "protecting my ideas" and "privacy" are alienated to me Emoji

The filling of the Earth with "garbaged" goods is nothing new, but as a traditional mean to keep the Third World countries stayed in their places. But there is a new dangerous trend, which is the bankruptcy of the old developed countries, for example, Ukraine and Greece. From First World countries in the past, they now become Third World countries. It means that the whole World is declining, just like the collapse of Roman Empire in the past. I afraid that we have to experience a short era of barbarism, with those Neo-Nazi and ISIS are clear examples.

Regards,
Đặng Minh Công

Фига се чувак жжот
Свой пацан в доску...

Ну и обходиться без FORWARD объявлений, как в AO!!!

Кстати я его компилятор тестирую тоже, так что если что, с багами помогу...
Ну и хотелось бы конечно без DLL, одним файлом... Что бы потом под платформы всякие попробывать!

My suggestion is to make a separated CONSTDATA section, so that the syntax of CONST section will be the same as in other Oberon dialects:

INT8, INT16, INT32, CARD16, CARD32 types

Reason for introducing: Same as BYTE type, in order to economise the use of memory.

Note: Type inclusion is not the same as in Oberon-2/Component Pascal. All the integer types: BYTE, INT8, CARD16, INT16, CARD32, INT32 and INTEGER are interchangable. All integer variables when loaded to register are signed extended to 64-bit INTEGER type. All integer calculation results are 64-bit INTEGER. That means BYTE + BYTE = INTEGER. Therefore, there is no speed benefit for using small integer types over INTEGER type. The programmer should use only INTEGER type for most of cases, which is good programming practice.

Note: There is no range checking in assignments between integer types!

Note: The 64-bit CARDINAL is not introduced, because 64-bit INTEGER is big enough, and also because of you cannot loselessly convert CARDINAL to INTEGER.

And for interfacing with Win32 API, I had to introduce typed-ADDRESS types and multiple INTEGER types into Oberon language, a step back to Modula-2 era.