Modula-2 Reloaded

A Modern Typesafe & Literate Programming Notation

Site Menu

Project

Specification

Implementation

Recommendations

Reference

Needs Updating

Work in Progress

Wastebasket

Wiki Manual

edit SideBar

Project FAQ

FAQ

Project.FAQ History

Hide minor edits - Show changes to output

2015-10-09 17:15 by trijezdci -
Changed line 135 from:
No, thank you. We cannot afford to engage in activities that would only distract us from our core mission while contributing little if anything towards our goals. We need to stay focused on the mission. Moreover, we have contributed a multi-dialect Modula-2 plugin to the Pygments rendering framework which Bitbucket is using. If we migrated away from Bitbucket, there is a chance that the new repository host will use a different source code rendering framework and we would have to rewrite our plugin, which would be entirely unnecessary double work.
to:
No, thank you. We cannot afford to engage in activities that would only distract us from our core mission while contributing little if anything towards our goals. We need to stay focused on the mission. Moreover, we have contributed a multi-dialect Modula-2 plugin to the Pygments source code rendering framework which Bitbucket is using. If we migrated away from Bitbucket, there is a chance that the new repository host will use a different rendering framework and we would have to rewrite our plugin, which would be entirely unnecessary double work.
2015-10-09 14:55 by trijezdci -
Changed line 31 from:
Within the context of our project's goals and design principles, the top five shortcomings of Ada are (1) user defined `ADTs are not first-class, (2) overall too large and too complex, (3) too many features with rare use cases (4) too heavy on synonym syntax, that is different ways to express what is essentially the same construct, (5) language report is too heavy on Ada specific terminology which makes it very difficult to comprehend.
to:
Within the context of our project's goals and design principles, the top five shortcomings of Ada are (1) user defined `ADTs are not first-class, (2) overall too large and too complex, (3) too many features with rare use cases, (4) too heavy on synonym syntax, that is different ways to express what is essentially the same construct, (5) language report is too heavy on Ada specific terminology which makes it very difficult to comprehend.
2015-10-09 14:54 by trijezdci -
Changed lines 38-40 from:
Within the context of our project's goals and design principles, the top five shortcomings of C are (1) user defined `ADTs are not first-class, (2) very poor type safety, (3) very poor readability (4) no separation of casting and conversion, (5) type promotion.

Within the context of our project's goals and design principles, the top five shortcomings of C++ are (1) overall too large and too complex, (2) too many features with rare use cases, (3) poor type safety, (4) very poor readability (5) type promotion.
to:
Within the context of our project's goals and design principles, the top five shortcomings of C are (1) user defined `ADTs are not first-class, (2) very poor type safety, (3) very poor readability, (4) no separation of casting and conversion, (5) type promotion.

Within the context of our project's goals and design principles, the top five shortcomings of C++ are (1) overall too large and too complex, (2) too many features with rare use cases, (3) poor type safety, (4) very poor readability, (5) type promotion.
2015-10-09 14:52 by trijezdci -
Changed lines 31-32 from:
Within the context of our project's goals and design principles, the most important shortcomings of Ada are (1) user defined `ADTs are not first-class, (2) overall too large and too complex, (3) too many features with rare use cases (4) too heavy on synonym syntax, that is different ways to express what is essentially the same construct, (5) language report is too heavy on Ada specific terminology which makes it very difficult to comprehend.
to:
Within the context of our project's goals and design principles, the top five shortcomings of Ada are (1) user defined `ADTs are not first-class, (2) overall too large and too complex, (3) too many features with rare use cases (4) too heavy on synonym syntax, that is different ways to express what is essentially the same construct, (5) language report is too heavy on Ada specific terminology which makes it very difficult to comprehend.
Changed lines 38-42 from:
Within the context of our project's goals and design principles, the most important shortcomings of C are (1) user defined `ADTs are not first-class, (2) very poor type safety, (3) very poor readability (4) no separation of casting and conversion, (5) type promotion.

Within the context of our project's goals and design principles, the most important shortcomings of C are (1) overall too large and too complex, (2) too many features with rare use cases, (3) poor type safety, (4) very poor readability (5) no separation of casting and conversion.

to:
Within the context of our project's goals and design principles, the top five shortcomings of C are (1) user defined `ADTs are not first-class, (2) very poor type safety, (3) very poor readability (4) no separation of casting and conversion, (5) type promotion.

Within the context of our project's goals and design principles, the top five shortcomings of C++ are (1) overall too large and too complex, (2) too many features with rare use cases, (3) poor type safety, (4) very poor readability (5) type promotion.

Changed line 48 from:
Within the context of our project's goals and design principles, the most important shortcomings of Oberon are (1) user defined `ADTs are not first-class, (2) no separation of interface and implementation, (3) absence of enumeration types, (4) absence of structured literals, (5) poor readability of number literals.
to:
Within the context of our project's goals and design principles, the top five shortcomings of Oberon are (1) user defined `ADTs are not first-class, (2) no separation of interface and implementation, (3) absence of enumeration types, (4) absence of structured literals, (5) poor readability of number literals.
2015-10-09 14:49 by trijezdci -
Added lines 31-32:
Within the context of our project's goals and design principles, the most important shortcomings of Ada are (1) user defined `ADTs are not first-class, (2) overall too large and too complex, (3) too many features with rare use cases (4) too heavy on synonym syntax, that is different ways to express what is essentially the same construct, (5) language report is too heavy on Ada specific terminology which makes it very difficult to comprehend.
Added lines 37-41:

Within the context of our project's goals and design principles, the most important shortcomings of C are (1) user defined `ADTs are not first-class, (2) very poor type safety, (3) very poor readability (4) no separation of casting and conversion, (5) type promotion.

Within the context of our project's goals and design principles, the most important shortcomings of C are (1) overall too large and too complex, (2) too many features with rare use cases, (3) poor type safety, (4) very poor readability (5) no separation of casting and conversion.

2015-10-09 14:35 by trijezdci -
Changed lines 41-42 from:
Within the context our our project's goals and design principles, the most important shortcomings of Oberon are (1) user defined `ADTs are not first-class, (2) no separation of interface and implementation, (3) absence of enumeration types, (4) absence of structured literals, (5) poor readability of number literals.
to:
Within the context of our project's goals and design principles, the most important shortcomings of Oberon are (1) user defined `ADTs are not first-class, (2) no separation of interface and implementation, (3) absence of enumeration types, (4) absence of structured literals, (5) poor readability of number literals.
Changed line 128 from:
No thank you, we cannot afford to engage in activities that would only distract us from our core mission while contributing little if anything towards our goals. We need to stay focused on the mission. Moreover, we have contributed a multi-dialect Modula-2 plugin to the Pygments rendering framework which Bitbucket is using. If we migrated away from Bitbucket, there is a chance that the new repository host will use a different source code rendering framework and we would have to rewrite our plugin, which would be entirely unnecessary double work.
to:
No, thank you. We cannot afford to engage in activities that would only distract us from our core mission while contributing little if anything towards our goals. We need to stay focused on the mission. Moreover, we have contributed a multi-dialect Modula-2 plugin to the Pygments rendering framework which Bitbucket is using. If we migrated away from Bitbucket, there is a chance that the new repository host will use a different source code rendering framework and we would have to rewrite our plugin, which would be entirely unnecessary double work.
2015-10-09 14:33 by trijezdci -
Added lines 41-42:
Within the context our our project's goals and design principles, the most important shortcomings of Oberon are (1) user defined `ADTs are not first-class, (2) no separation of interface and implementation, (3) absence of enumeration types, (4) absence of structured literals, (5) poor readability of number literals.
Changed lines 125-126 from:

to:
[[#ChoiceOfRepository]]
!!!!! So your repo is on Bitbucket. Will you migrate to my favourite alternative?

No thank you, we cannot afford to engage in activities that would only distract us from our core mission while contributing little if anything towards our goals. We need to stay focused on the mission. Moreover, we have contributed a multi-dialect Modula-2 plugin to the Pygments rendering framework which Bitbucket is using. If we migrated away from Bitbucket, there is a chance that the new repository host will use a different source code rendering framework and we would have to rewrite our plugin, which would be entirely unnecessary double work.
2015-10-01 09:19 by trijezdci -
Changed lines 24-25 from:
We participated in and learned from the ISO standardisation but preferred to start out with the simpler design defined by Wirth. We carefully considered each feature in view of our own design principles and only adopted those that passed our rigid scrutiny. From ISO Modula-2 we adopted the CAST function, structured values and pragma delimiters. In comparison to ISO Modula-2, our design and our standard library are simpler, but more robust and extensible.
to:
We participated in and learned from the ISO standardisation but preferred to start out with the simpler design defined by Wirth. We carefully considered each feature in view of our own design principles and only adopted those that passed our rigid scrutiny. From ISO Modula-2 we adopted the @@CAST@@ function, structured values and pragma delimiters. In comparison to ISO Modula-2, our design and our standard library are simpler, but more robust and extensible.
Changed lines 91-96 from:
!!!!! You replaced the FOR TO BY with a FOR IN loop. Why the change?

The FOR TO BY loop is sufficient for iterating over an ordinal type or an indexed collection such as an array. In this day and age, data structures such as sets, trees and dictionaries take a far more prominent role than back in the day when classic Modula-2 was defined. To iterate over those data structures the FOR TO BY loop is insufficient, a FOR IN loop is required instead.

We did not want to maintain two separate FOR loops, one for ordinal types and another for collections. Instead we designed a FOR IN loop that also accommodates ordinal types and thus replaced the FOR TO BY loop altogether.
to:
!!!!! You replaced the @@FOR@@ @@TO@@ @@BY@@ with a @@FOR@@ @@IN@@ loop. Why the change?

The @@FOR@@ @@TO@@ @@BY@@ loop is sufficient for iterating over an ordinal type or an indexed collection such as an array. In this day and age, data structures such as sets, trees and dictionaries take a far more prominent role than back in the day when classic Modula-2 was defined. To iterate over those data structures the @@FOR@@ @@TO@@ @@BY@@ loop is insufficient, a @@FOR@@ @@IN@@ loop is required instead.

We did not want to maintain two separate @@FOR@@ loops, one for ordinal types and another for collections. Instead we designed a FOR IN loop that also accommodates ordinal types and thus replaced the @@FOR@@ @@TO@@ @@BY@@ loop altogether.
Changed lines 98-103 from:
!!!!! You renamed pseudo-module SYSTEM to UNSAFE. Why the change?

Professor Wirth introduced pseudo-module SYSTEM to mark the use of non-portable and unsafe language features through import from SYSTEM. However, this is a classical case of a misnomer because not every system level feature is non-portable or unsafe, and not every non-portable or unsafe feature is a system level facility. In classical Modula-2 unsafe features remained in the language without requiring import from SYSTEM. If the primary purpose of the module was to house unsafe features, then it should be named accordingly.

Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type transfer is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and its use is stigmatised, leading to a culture of caution.
to:
!!!!! You renamed pseudo-module @@SYSTEM@@ to @@UNSAFE@@. Why the change?

Professor Wirth introduced pseudo-module @@SYSTEM@@ to mark the use of non-portable and unsafe language features through import from @@SYSTEM@@. However, this is a classical case of a misnomer because not every system level feature is non-portable or unsafe, and not every non-portable or unsafe feature is a system level facility. In classical Modula-2 unsafe features remained in the language without requiring import from @@SYSTEM@@. If the primary purpose of the module was to house unsafe features, then it should be named accordingly.

Using @@UNSAFE@@ instead of @@SYSTEM@@ also serves a psychological purpose. C practitioners are not usually aware when a type transfer is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as @@UNSAFE.CAST@@, awareness is raised and its use is stigmatised, leading to a culture of caution.
Changed lines 105-107 from:
!!!!! You added a new compilation unit BLUEPRINT? What for and why?

Our revision supports first class user definable abstract data types. That is to say, user defined data types may bind to built-in syntax such as the NEW and RELEASE statements, the FOR IN loop, operators and predefined functions and procedures. In practise user defined data types thereby become indistinguishable from built-in types. This eliminates one of the primary causes for feature growth in the core language.
to:
!!!!! You added a new compilation unit @@BLUEPRINT@@? What for and why?

Our revision supports first class user definable abstract data types. That is to say, user defined data types may bind to built-in syntax such as the @@NEW@@ and @@RELEASE@@ statements, the @@FOR@@ @@IN@@ loop, operators and predefined functions and procedures. In practise user defined data types thereby become indistinguishable from built-in types. This eliminates one of the primary causes for feature growth in the core language.
2015-10-01 09:12 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was ''"An engineer measures twice and cuts once"''. This is in stark contrast to today's prevailing mottos ''"because we can, it's cool"'' and ''"ship early, fix later"''. Back then not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was ''"An engineer measures twice and cuts once"''. This is in stark contrast to today's mottos ''"because we can, it's cool"'' and ''"ship early, fix later"''. Back then not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-10-01 09:09 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "ship early, fix later" attitude and "because its cool" zealotry, not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was ''"An engineer measures twice and cuts once"''. This is in stark contrast to today's prevailing mottos ''"because we can, it's cool"'' and ''"ship early, fix later"''. Back then not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-10-01 09:06 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" attitude, not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "ship early, fix later" attitude and "because its cool" zealotry, not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-10-01 09:04 by trijezdci -
Changed line 4 from:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, contemporary programming notations mostly don't.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, contemporary notations mostly don't.
2015-10-01 09:03 by trijezdci -
Changed line 4 from:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, today's programming notations mostly don't.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, contemporary programming notations mostly don't.
2015-10-01 09:03 by trijezdci -
Changed line 4 from:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, modern programming notations mostly don't.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, today's programming notations mostly don't.
2015-10-01 09:02 by trijezdci -
Changed line 4 from:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles, modern programming notations mostly don't.
2015-10-01 09:01 by trijezdci -
Changed line 4 from:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one. The goal was a notation that adheres to engineering principles.
2015-09-17 10:40 by trijezdci -
Changed line 29 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). When software is compiled with GNAT it becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). When software is compiled with GNAT it becomes GPL encumbered. Commercial Ada compilers are rare and very expensive. Pricing is not publicly available.
2015-09-17 10:26 by trijezdci -
Changed line 29 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). Unlike most free compilers for other languages, when software is compiled with GNAT it becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). When software is compiled with GNAT it becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
2015-09-17 10:23 by trijezdci -
Changed line 29 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). Software compiled with GNAT becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). Unlike most free compilers for other languages, when software is compiled with GNAT it becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
2015-09-17 10:21 by trijezdci -
Changed line 29 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are rare and very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT). Software compiled with GNAT becomes GPL encumbered. Commercial Ada compilers are rare and very expensive.
2015-09-17 10:01 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data at will and with impunity. Over the same period software has become overly complex, heavy and unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data at will and with impunity. Over the same period software has become overly complex, heavy and unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset, programming languages and associated tools have been proliferating security and reliability issues for many years.
2015-09-17 09:57 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data at will and with impunity. Over the same period software has become overly complex, heavy and unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
2015-09-17 09:57 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
2015-09-17 09:54 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" attitude, not everything that was possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-09-17 09:51 by trijezdci -
Changed line 111 from:
We introduced blueprints as a means to enforce the integrity and consistency of bindings to built-in syntax. A user defined data type may only bind to built-in syntax if it declares conformity to a blueprint. In turn, a blueprint imposes constraints and requirements on what bindings must be provided. Our standard library includes a rich set of predefined blueprints for numeric and collection ADTs.
to:
We introduced blueprints as a means to enforce the integrity and consistency of bindings to built-in syntax. A user defined data type may only bind to built-in syntax if it declares conformity to a blueprint. In turn, a blueprint imposes constraints and requirements on what bindings must be provided. Our standard library includes a rich set of predefined blueprints for numeric and collection [=ADTs=].
2015-09-17 09:49 by trijezdci -
Changed lines 107-111 from:
to do
to:
Our revision supports first class user definable abstract data types. That is to say, user defined data types may bind to built-in syntax such as the NEW and RELEASE statements, the FOR IN loop, operators and predefined functions and procedures. In practise user defined data types thereby become indistinguishable from built-in types. This eliminates one of the primary causes for feature growth in the core language.

However, when library defined data types are permitted to bind to built-in syntax there is an enormous potential for violating the consistency and integrity that is generally expected when using built-in syntax. A library defined integer type that looks as if it is built-in should be required to bind to all the syntax that a built-in integer type supports, no more and no less.

We introduced blueprints as a means to enforce the integrity and consistency of bindings to built-in syntax. A user defined data type may only bind to built-in syntax if it declares conformity to a blueprint. In turn, a blueprint imposes constraints and requirements on what bindings must be provided. Our standard library includes a rich set of predefined blueprints for numeric and collection ADTs.
2015-09-17 08:00 by trijezdci -
Changed line 29 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are rare and very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler and verifying its correctness is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are rare and very expensive.
2015-09-17 07:58 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible to do was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no others. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-09-17 07:17 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was firmly rooted in engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-09-17 07:15 by trijezdci -
Changed line 4 from:
It seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one.
to:
In short, it seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one.
2015-09-17 07:10 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
to:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity principles and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.
2015-09-17 07:09 by trijezdci -
Changed lines 8-10 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
to:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises.

Somebody had to bring it back. We adopted this as our mission.
2015-09-17 07:09 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
to:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the prevailing mindset. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
2015-09-17 07:08 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
to:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
2015-09-17 07:07 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues for many years.
2015-09-17 07:07 by trijezdci -
Changed lines 6-8 from:
Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. Prevailing mindset and tools have been proliferating security and reliability issues.

Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". Not everything possible of doing was also worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unlike Modula-2, Ada does not follow Einsteinian simplicity and unfortunately it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody has to bring it back. We adopted this as our mission.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. By exploiting vulnerabilities, determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. The prevailing mindset and tools have been proliferating security and reliability issues.

Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". In a stark contrast to today's "Because we can" mindset, not everything possible of doing was also considered worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unlike Modula-2 though, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody had to bring it back. We adopted this as our mission.
2015-09-17 07:02 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools. Prevailing mindset and tools have been proliferating security and reliability issues.
2015-09-17 07:00 by trijezdci -
Changed line 8 from:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". Not everything possible of doing was also worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unfortunately, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of today's software practitioners. Modula-2 once educated an entire generation in best practises. Somebody has to bring it back. We adopted this as our mission.
to:
Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". Not everything possible of doing was also worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unlike Modula-2, Ada does not follow Einsteinian simplicity and unfortunately it has not managed to influence the mindset of software practitioners. Modula-2 once educated an entire generation in best practises. Somebody has to bring it back. We adopted this as our mission.
2015-09-17 06:58 by trijezdci -
Changed line 6 from:
Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of practitioners and their development tools.
to:
Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of software practitioners and their development tools.
2015-09-17 06:57 by trijezdci -
Changed lines 4-5 from:
to do
to:
It seemed more promising to modify a thirty year old notation and modernise it than to try to fix a contemporary one.

Over the last thirty years, the world of information technology has become a very dangerous place. Determined attackers can walk right into our computers and devices to sabotage them or steal data all over the world at will and with impunity. Over the same period software has become overly complex and more and more unreliable. All this is a result of a change in the mindset of practitioners and their development tools.

Thirty years ago, the prevailing mindset was based on engineering principles and best practises. The motto was "An engineer measures twice and cuts once". Not everything possible of doing was also worth doing. Safeguards took centre stage. Ada and Classic Modula-2 represent this mindset like no other. Unfortunately, Ada does not follow Einsteinian simplicity and it has not managed to influence the mindset of today's software practitioners. Modula-2 once educated an entire generation in best practises. Somebody has to bring it back. We adopted this as our mission.

Deleted line 115:
2015-09-17 01:47 by trijezdci -
Changed line 33 from:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it leads to language balkanisation and is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
to:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it also leads to language balkanisation and is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
2015-09-17 01:38 by trijezdci -
Changed line 96 from:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type transfer is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
to:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type transfer is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and its use is stigmatised, leading to a culture of caution.
2015-09-17 01:32 by trijezdci -
Changed line 96 from:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type conversion is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
to:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type transfer is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
2015-09-17 01:31 by trijezdci -
Changed line 96 from:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a cast is safe or unsafe because C terminology does not distinguish between the two cases. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
to:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a type conversion is safe or unsafe because C terminology does not distinguish the two cases, referring to both as casts. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
2015-09-17 01:28 by trijezdci -
Changed line 33 from:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it leads to language balkanisation is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
to:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it leads to language balkanisation and is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
2015-09-17 01:28 by trijezdci -
Changed line 28 from:
C and C++ are not safe and they are not literate. Their widespread use for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
to:
C and C++ are inherently unsafe and they are not literate. Their widespread use for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
2015-09-17 01:26 by trijezdci -
Changed line 23 from:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are very expensive.
to:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are rare and very expensive.
2015-09-17 01:25 by trijezdci -
Changed line 18 from:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO Modula-2's CAST function, structured values and pragma delimiters.
to:
We participated in and learned from the ISO standardisation but preferred to start out with the simpler design defined by Wirth. We carefully considered each feature in view of our own design principles and only adopted those that passed our rigid scrutiny. From ISO Modula-2 we adopted the CAST function, structured values and pragma delimiters. In comparison to ISO Modula-2, our design and our standard library are simpler, but more robust and extensible.
2015-09-16 12:29 by trijezdci -
Changed line 18 from:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and its pragma delimiters.
to:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO Modula-2's CAST function, structured values and pragma delimiters.
2015-09-16 12:28 by trijezdci -
Changed line 18 from:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and pragma delimiters.
to:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and its pragma delimiters.
2015-09-16 12:27 by trijezdci -
Changed line 18 from:
Having served on the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and pragma delimiters.
to:
Having participated in the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and pragma delimiters.
2015-09-16 12:27 by trijezdci -
Added lines 15-18:

!!!!! Wasn't there an ISO Modula-2 after Wirth's classic version? Why didn't you start out with that?

Having served on the ISO Modula-2 working group was an important experience for us to learn from the mistakes made back then. Unfortunately, there was very little design that was worth salvaging. However, we adopted ISO's CAST function, structured values and pragma delimiters.
2015-09-16 12:07 by trijezdci -
Changed line 107 from:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record, called the discriminant field. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field after which it becomes immutable. Runtime bounds checking is then performed using the discriminant value. The facility is entirely type safe.
to:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record, called the discriminant field. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field after which it becomes immutable and the array is not resizable. Runtime bounds checking is then performed using the discriminant value. The facility is entirely type safe.
2015-09-16 12:06 by trijezdci -
Changed line 107 from:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record, called the discriminant field. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field after which it becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
to:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record, called the discriminant field. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field after which it becomes immutable. Runtime bounds checking is then performed using the discriminant value. The facility is entirely type safe.
2015-09-16 12:06 by trijezdci -
Changed line 107 from:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field and after that the field becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
to:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record, called the discriminant field. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field after which it becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
2015-09-16 12:03 by trijezdci -
Changed line 107 from:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler must do bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field and after that the field becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
to:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler guarantees bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field and after that the field becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
2015-09-16 12:02 by trijezdci -
Changed lines 102-103 from:
to do
to:
The reason why variadic functions in C are unsafe is that no formal parameters are specified, they are effectively untyped. By contrast, in Modula-2 formal parameters are always typed and actual parameters must match formal types. We used the same principle in our design of variadic procedures in Modula-2. The facility is entirely type safe.
Changed line 107 from:
to do
to:
The reason why variable length arrays as they are called in C are unsafe is that C does not consider array bounds part of the type and consequently it does not do any bounds checking, neither on ordinary arrays, nor on variable length arrays. By contrast, in Modula-2 array bounds are always part of the type and the compiler must do bounds checking. We used the same principle in our design of indeterminate records. The size of the array that makes up the indeterminate field must be linked to another field in the record. When the record is allocated at runtime, the runtime system automatically stores the allocated size in the discriminant field and after that the field becomes immutable. Runtime bounds checking is then performed using the stored value. The facility is entirely type safe.
2015-09-16 09:47 by trijezdci -
Changed line 92 from:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a cast is safe or unsafe because C terminology does not distinguish between the two cases. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as CAST.UNSAFE, awareness is raised and use is stigmatised.
to:
Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a cast is safe or unsafe because C terminology does not distinguish between the two cases. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as UNSAFE.CAST, awareness is raised and use is stigmatised.
2015-09-16 09:47 by trijezdci -
Changed lines 90-92 from:
to do
to:
Professor Wirth introduced pseudo-module SYSTEM to mark the use of non-portable and unsafe language features through import from SYSTEM. However, this is a classical case of a misnomer because not every system level feature is non-portable or unsafe, and not every non-portable or unsafe feature is a system level facility. In classical Modula-2 unsafe features remained in the language without requiring import from SYSTEM. If the primary purpose of the module was to house unsafe features, then it should be named accordingly.

Using UNSAFE instead of SYSTEM also serves a psychological purpose. C practitioners are not usually aware when a cast is safe or unsafe because C terminology does not distinguish between the two cases. This has led to a culture of living dangerously without reflection. By explicitly spelling out a dangerous practise such as CAST.UNSAFE, awareness is raised and use is stigmatised.
2015-09-16 09:31 by trijezdci -
Changed line 85 from:
We did not want to accommodate two separate FOR loops, one for ordinal types and another for collections. Instead we designed a FOR IN loop that also accommodates ordinal types and thus replaced the FOR TO BY loop altogether.
to:
We did not want to maintain two separate FOR loops, one for ordinal types and another for collections. Instead we designed a FOR IN loop that also accommodates ordinal types and thus replaced the FOR TO BY loop altogether.
2015-09-16 09:30 by trijezdci -
Changed line 85 from:
We did not want to accommodate two separate FOR loops, one for ordinal types and arrays, and another for sets, trees and dictionaries. Instead we designed a FOR IN loop that also accommodates iterating over ordinal types and thus replaced the FOR TO BY loop.
to:
We did not want to accommodate two separate FOR loops, one for ordinal types and another for collections. Instead we designed a FOR IN loop that also accommodates ordinal types and thus replaced the FOR TO BY loop altogether.
2015-09-16 09:29 by trijezdci -
Changed lines 83-85 from:
to do
to:
The FOR TO BY loop is sufficient for iterating over an ordinal type or an indexed collection such as an array. In this day and age, data structures such as sets, trees and dictionaries take a far more prominent role than back in the day when classic Modula-2 was defined. To iterate over those data structures the FOR TO BY loop is insufficient, a FOR IN loop is required instead.

We did not want to accommodate two separate FOR loops, one for ordinal types and arrays, and another for sets, trees and dictionaries. Instead we designed a FOR IN loop that also accommodates iterating over ordinal types and thus replaced the FOR TO BY loop.
2015-09-16 09:09 by trijezdci -
Changed lines 74-78 from:
to do
to:
First and foremost, variant record types are fragile. It is not possible to anticipate all future variants. If and when a new variant needs to be added later, the change will break all client libraries using the type, even if the client libraries are not making any use of the newly added variant. In the world of OOP this is known as the fragile base class problem.

Secondly, most implementations of variant records superimpose variant fields to save memory usage. Without a safeguard that only allows retrieval of that variant which has actually been stored, but not any other variant, such an implementation is not type safe. Of all the languages that provide variant record types, Ada is probably the only one that employs such a safeguard and it is quite complex.

In Oberon, Professor Wirth introduced extensible record types as an alternative to variant record types. Wirth's solution solves both issues in an elegant fashion and with simplicity. Naturally, we adopted this superior approach.
2015-09-16 08:41 by trijezdci -
Changed line 47 from:
Many operating system and library [=APIs=] pass unsigned types back and forth. When interfacing with these [=APIs=] from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. To express all addresses in a linear fashion an unsigned type is required, or a larger unsigned type. Alternatively, if the negative values of an unsigned type are to be used, the address space is no longer linear.
to:
Many operating system and library [=APIs=] pass unsigned types back and forth. When interfacing with these [=APIs=] from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. To express all addresses in a linear fashion an unsigned type or a larger signed type is required. Alternatively, if the negative values of an unsigned type are to be used, the address space is no longer linear.
2015-09-16 08:06 by trijezdci -
Changed line 69 from:
As a general rule, prefixed literals are both easier to read and less effort to parse than suffixed literals. In addition, the B and C suffixes used by classic Modula-2 were also legal base-16 digits, making such literals particularly confusing and very hard to parse when applying a one-character lookahead. The prefix based literal notation popularised by C is far better readable, especially when using a lowercase prefix. It is also far less effort to parse, even when applying a one-character lookahead.
to:
As a general rule, prefixed literals are both easier to read and less effort to parse than suffixed literals. In addition, the B and C suffixes used by classic Modula-2 were also legal base-16 digits, making such literals particularly confusing and very hard to parse when applying a one-character lookahead. The prefix based literal notation popularised by C is far better readable, especially when using a lowercase prefix. It is also far less effort to parse, in particular when applying a one-character lookahead.
2015-09-16 08:05 by trijezdci -
Changed line 69 from:
to do
to:
As a general rule, prefixed literals are both easier to read and less effort to parse than suffixed literals. In addition, the B and C suffixes used by classic Modula-2 were also legal base-16 digits, making such literals particularly confusing and very hard to parse when applying a one-character lookahead. The prefix based literal notation popularised by C is far better readable, especially when using a lowercase prefix. It is also far less effort to parse, even when applying a one-character lookahead.
2015-09-16 07:32 by trijezdci -
Changed line 54 from:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not out of range but very few actually do so. This is a very important area of safety that should never be compromised.
to:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) programmers must manually check that values are not out of range but very few actually do so. This is a very important area of safety that should never be compromised.
2015-09-16 07:31 by trijezdci -
Changed line 54 from:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not out of range. This is a very important area of safety that should never be compromised.
to:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not out of range but very few actually do so. This is a very important area of safety that should never be compromised.
2015-09-16 07:26 by trijezdci -
Changed line 56 from:
Professor Wirth stated the potential of name collisions when importing an enumeration type as a reason for its removal. In our revision we require that enumerated values are qualified with the type identifier, thereby solving the problem of potential name collisions on import in a different way.
to:
Professor Wirth stated the potential of name collisions when importing an enumeration type as a reason for removal. In our revision we require that enumerated values are qualified with the type identifier, thereby solving the problem of potential name collisions on import in a different way.
2015-09-16 07:25 by trijezdci -
Changed line 54 from:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not our of range. This is a very important area of safety that should never be compromised.
to:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not out of range. This is a very important area of safety that should never be compromised.
2015-09-16 07:24 by trijezdci -
Changed line 54 from:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a parameter or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not our of range. This is a very important area of safety that should never be compromised.
to:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a variable or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not our of range. This is a very important area of safety that should never be compromised.
2015-09-16 07:23 by trijezdci -
Added lines 73-74:

to do
2015-09-16 07:19 by trijezdci -
Changed line 62 from:
When we asked Professor Wirth about his experience with type promotion, or type inclusion, as it is called in Oberon terminology, he responded "Type inclusion turned out to have been an incredibly bad idea. I have removed it in my latest revision of Oberon."!
to:
When we asked Professor Wirth about his experience with type promotion, or type inclusion as it is called in Oberon terminology, he responded "Type inclusion turned out to have been an incredibly bad idea. I have removed it in my latest revision of Oberon."!!!
2015-09-16 07:18 by trijezdci -
Changed line 62 from:
When we asked Professor Wirth about his experience with type promotion, or type inclusion in Oberon terminology, he responded "Type inclusion turned out to have been an incredibly bad idea. I have removed it in my latest revision of Oberon."!
to:
When we asked Professor Wirth about his experience with type promotion, or type inclusion, as it is called in Oberon terminology, he responded "Type inclusion turned out to have been an incredibly bad idea. I have removed it in my latest revision of Oberon."!
2015-09-16 07:17 by trijezdci -
Changed lines 62-64 from:
to do
to:
When we asked Professor Wirth about his experience with type promotion, or type inclusion in Oberon terminology, he responded "Type inclusion turned out to have been an incredibly bad idea. I have removed it in my latest revision of Oberon."!

We have been using C for too long not to know just how bad this feature really is. In general terms, implicit magic is almost always a bad thing because it can lead to misinterpretation and subsequent introduction of errors. Type promotion is one such implicit magic. In our revision we require explicit type conversion. This is so central to our design that we added a dedicated type conversion operator.
2015-09-16 07:11 by trijezdci -
Changed lines 54-57 from:
to do
to:
Enumerations provide type safety. A language with true enumeration types guarantees that no invalid values can be used for a parameter or parameter of an enumeration type. In a language without enumeration types, or with fake enumeration types (such as C) the programmer must manually check that values are not our of range. This is a very important area of safety that should never be compromised.

Professor Wirth stated the potential of name collisions when importing an enumeration type as a reason for its removal. In our revision we require that enumerated values are qualified with the type identifier, thereby solving the problem of potential name collisions on import in a different way.

2015-09-16 07:04 by trijezdci -
Changed line 49 from:
If Modula-2 had no unsigned type, and used a signed type of the same size instead, the replacement type would then need to be interpreted with unsigned semantics which would diminish clarity and provide opportunity for error. To read a file, the file's index would need to be incremented for the first half of the address space and then counter-intuitively decremented for the second half. This is ugly, confusing and not worthy of a literate programming language.
to:
If Modula-2 had no unsigned type, and used a signed type of the same size instead, the replacement type would then need to be interpreted with unsigned semantics which would diminish clarity and provide opportunity for error. To read a file of a file system that uses an address space of the bit-width of the largest integer, the file's index would need to be incremented for the first half of the address space and then counter-intuitively decremented for the second half. This is ugly, confusing and not worthy of a literate programming language.
2015-09-16 07:02 by trijezdci -
Changed lines 47-49 from:
Many operating system and library [=APIs=] pass unsigned types back and forth. When interfacing with these [=APIs=] from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. As filesystems and databases use 64-bit addressing, the largest address would need an unsigned 64-bit type or a 72-bit or larger signed type.

If Modula-2 had no
unsigned type, and used a signed type of the same size instead, the replacement type would then need to be interpreted with unsigned semantics which would diminish clarity and provide opportunity for error. For example, to read a file, the file's index would need to be incremented for the first half of available indices and then decremented for the second half. This is certainly most counter-intuitive and not worthy of a literate programming language.
to:
Many operating system and library [=APIs=] pass unsigned types back and forth. When interfacing with these [=APIs=] from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. To express all addresses in a linear fashion an unsigned type is required, or a larger unsigned type. Alternatively, if the negative values of an unsigned type are to be used, the address space is no longer linear.

If Modula-2 had no unsigned type, and used a signed type of the same size instead, the replacement type would then need
to be interpreted with unsigned semantics which would diminish clarity and provide opportunity for error. To read a file, the file's index would need to be incremented for the first half of the address space and then counter-intuitively decremented for the second half. This is ugly, confusing and not worthy of a literate programming language.
2015-09-16 06:57 by trijezdci -
Changed lines 47-48 from:
Many operating system and library APIs pass unsigned types back and forth. When interfacing with these APIs from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. As filesystems and databases use 64-bit addressing, the largest address would need an unsigned 64-bit type or a 72-bit or larger signed type.
to:
Many operating system and library [=APIs=] pass unsigned types back and forth. When interfacing with these [=APIs=] from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. As filesystems and databases use 64-bit addressing, the largest address would need an unsigned 64-bit type or a 72-bit or larger signed type.
Deleted line 92:
2015-09-16 06:56 by trijezdci -
Changed lines 45-49 from:
to do
to:
We have taken Professor Wirth's dislike of unsigned types into consideration but found that their removal would come at the expense of both readability and utility. Consequently we could not justify their removal. There are two important use cases which we believe deserve language support.

Many operating system and library APIs pass unsigned types back and forth. When interfacing with these APIs from Modula-2 it is necessary to pass and receive unsigned types. Furthermore, when implementing filesystems and databases, an unsigned type is required to represent the index of addressable content cells. As filesystems and databases use 64-bit addressing, the largest address would need an unsigned 64-bit type or a 72-bit or larger signed type.

If Modula-2 had no unsigned type, and used a signed type of the same size instead, the replacement type would then need to be interpreted with unsigned semantics which would diminish clarity and provide opportunity for error. For example, to read a file, the file's index would need to be incremented for the first half of available indices and then decremented for the second half. This is certainly most counter-intuitive and not worthy of a literate programming language.
2015-09-16 06:19 by trijezdci -
Changed line 14 from:
No. Backwards compatibility was not a design goal. There are a number of changes that render legacy sources in classic Modula-2 incompatible with the revised language. For the migration of legacy code we intend to provide a source-to-source translator.
to:
No. The language has been out of favour for so long that backwards compatibility was not a design goal. There are a number of changes that render legacy sources in classic Modula-2 incompatible with the revised language. For the migration of legacy code we intend to provide a source-to-source translator.
2015-09-16 06:18 by trijezdci -
Changed line 9 from:
Professor Wirth has given us permission to use the Modula-2 name.
to:
Professor Wirth has given us permission to use the Modula-2 name for a modernisation of the language.
2015-09-16 06:14 by trijezdci -
Changed lines 34-40 from:
to do
to:
Modula-2 is a descendant of Algol. When Algol was specified there was no standard yet for character encoding. All the designers could do was to define how Algol source code would be presented in print while leaving the encoding implementation dependent. The Algol-60 report presented reserved words in lowercase boldface underlined and predefined names in lowercase boldface italic. This established a de-facto standard for the publication of algorithms that is still in use today, albeit minus the underlining.

Since there was no standard way to represent boldface and italic on computer hardware at the time, Algol implementations used a technique called stropping to tag reserved words and predefined names. Some implementations used leading or trailing apostrophes, some used national currency symbols. When both uppercase and lowercase character sets became widely available, Wirth used uppercase in his Algol-W language as a form of stropping. Modula-2 follows this approach.

The benefit of uppercase stropping is two-fold. It makes reserved words and predefined names stand out even in the absence of any formatting and colouring and thereby contributes to readability of source code. Further, it allows the addition of new reserved words and predefined names when the language undergoes a revision without concern for name collision with existing legacy code. By contrast, in C, language revisions have added reserved words and predefined names with leading and trailing lowline characters.

However, the recommended presentation for Modula-2 remains that of the Algol-60 report, minus the underlining. To that end we have contributed a multi-dialect rendering plug-in for Modula-2 to the Pygments source code rendering framework. Our plug-in supports an Algol rendering mode by which reserved words are rendered in lowercase boldface and predefined names in lowercase boldface italic. We intend to provide similar plug-ins to other frameworks and for various source code editors.
2015-09-16 05:51 by trijezdci -
Changed line 24 from:
C and C++ are not safe and they are not literate. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
to:
C and C++ are not safe and they are not literate. Their widespread use for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
2015-09-16 05:48 by trijezdci -
Changed line 24 from:
C and C++ are not safe. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
to:
C and C++ are not safe and they are not literate. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
2015-09-16 05:46 by trijezdci -
Changed line 24 from:
C and C++ are not safe. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must be abandoned in the long term.
to:
C and C++ are not safe. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must eventually be abandoned altogether.
2015-09-16 05:45 by trijezdci -
Added lines 81-82:

to do
2015-09-16 05:43 by trijezdci -
Added lines 4-5:
to do
Changed lines 29-30 from:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
to:
The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it leads to language balkanisation is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
Added lines 34-35:
to do
Added lines 39-40:
to do
Added lines 44-45:
to do
Added lines 49-50:
to do
Added lines 54-55:
to do
Added lines 62-63:
to do
Added lines 67-68:
to do
Added lines 72-73:
to do
Added lines 76-77:

to do
2015-09-16 05:41 by trijezdci -
Added lines 17-18:
Ada is a very large language. It has a very steep learning curve and developers are hard to find. Building an Ada compiler is an immense undertaking. The only available free compiler is the GNU Ada Translator (GNAT) which is GPL licensed and commercial compilers are very expensive.
Added lines 22-23:
C and C++ are not safe. The widespread use of C/C++ for system software is a major root cause for most of the world's information security problems. These languages do not solve but proliferate security issues. To reach a future in which information systems are safe, their use must be abandoned in the long term.
Added lines 26-27:

The approach Professor Wirth has taken with Oberon is best described as custom dialect development on a per project basis, leaving out everything that is not strictly required by the project for which the dialect is custom made. This approach leads to very lean language designs but it is not suitable for large industrial projects where software reuse and interfacing to existing technologies is important.
2015-09-16 05:22 by trijezdci -
Changed line 12 from:
No. Backwards compatibility was not a design goal. There are a number of changes that render legacy sources in classic Modula-2 incompatible. For the migration of legacy code we intend to provide a source-to-source translator.
to:
No. Backwards compatibility was not a design goal. There are a number of changes that render legacy sources in classic Modula-2 incompatible with the revised language. For the migration of legacy code we intend to provide a source-to-source translator.
2015-09-16 05:22 by trijezdci -
Changed lines 7-8 from:
Professor Wirth has granted us permission to use the Modula-2 name.
to:
Professor Wirth has given us permission to use the Modula-2 name.
Added lines 11-12:

No. Backwards compatibility was not a design goal. There are a number of changes that render legacy sources in classic Modula-2 incompatible. For the migration of legacy code we intend to provide a source-to-source translator.
2015-09-16 05:17 by trijezdci -
Added lines 6-7:

Professor Wirth has granted us permission to use the Modula-2 name.
2015-09-16 05:15 by trijezdci -
Added line 1:
[[#RevivalMotive]]
Added line 4:
[[#PermissionToUseName]]
Added line 7:
[[#BackwardsCompatibility]]
Added lines 10-19:
[[#WhyNotAda]]
!!!!! If safety and readability is of concern, why not use Ada?

[[#WhyNotCOrCpp]]
!!!!! If you need to do systems programming, why not use C/C++?

[[#WhyNotOberon]]
!!!!! If you like simplicity in a language, why not use Oberon?

[[#Uppercase]]
Added line 22:
[[#Cardinals]][[#UnsignedIntegers]]
Added line 25:
[[#Enumerations]]
Added line 28:
[[#TypePromotionIsEvil]][[#TypeInclusionIsEvil]]
Added line 31:
[[#ClikeNumbers]]
Added line 34:
[[#VariantVersusExtensibleRecords]]
Added line 37:
[[#ForToByVersusForIn]]
Added line 40:
[[#SystemVersusUnsafe]]
Added line 43:
[[#Blueprints]]
Added line 46:
[[#VariadicParameters]]
Added line 49:
[[#IndeterminateRecords]]
Deleted lines 50-56:

!!!!! If safety and readability is of concern, why not use Ada?

!!!!! If you need to do systems programming, why not use C/C++?

!!!!! If you like simplicity in a language, why not use Oberon?

2015-09-16 05:07 by trijezdci -
Added lines 28-37:

!!!!! If safety and readability is of concern, why not use Ada?

!!!!! If you need to do systems programming, why not use C/C++?

!!!!! If you like simplicity in a language, why not use Oberon?



2015-09-16 04:56 by trijezdci -
Added lines 12-13:

!!!!! In Oberon, Wirth introduced type promotion. Why didn't you follow that?
2015-09-16 04:53 by trijezdci -
Changed line 23 from:
!!!!! You permit variadic parameters, known from C. I Is that type safe?
to:
!!!!! You permit variadic parameters, known from C. Is that type safe?
2015-09-16 04:52 by trijezdci -
Changed lines 1-2 from:

!!!!! Why revive a long-forgotten 30-old programming language?
to:
!!!!! Why revive a long-forgotten 30-year old programming language?
2015-09-16 04:51 by trijezdci -
Added lines 1-28:

!!!!! Why revive a long-forgotten 30-old programming language?

!!!!! Who gave you permission to use the Modula-2 name?

!!!!! Is the revision backwards compatible with the classic language?

!!!!! What's up with those UPPERCASE words? Why didn't you change that?

!!!!! In Oberon, Wirth removed type CARDINAL. Why didn't you follow that?

!!!!! In Oberon, Wirth removed enumerations. Why didn't you follow that?

!!!!! You are using C-like number literals. Why the change?

!!!!! You replaced variant records with extensible records. Why the change?

!!!!! You replaced the FOR TO BY with a FOR IN loop. Why the change?

!!!!! You renamed pseudo-module SYSTEM to UNSAFE. Why the change?

!!!!! You added a new compilation unit BLUEPRINT? What for and why?

!!!!! You permit variadic parameters, known from C. I  Is that type safe?

!!!!! You permit an indeterminate field in records, known from C. Is that type safe?