HPA111@DE0HRZ1A.BITNET (Michael Drechsler) (05/18/88)
Hello, I'm currently reading the logfile of the March discussions of this list. It contains many articles about a Wirth paper called "From Modula to Oberon". Does anyone of you has this paper online? If so, could you please send it to me? Or is this a real sheet of paper, unable to be e-mailed? In case of a real paper, in what journal/magazine/whateverelse has it been published? Thanks in advance, Michael HPA111@DE0HRZ1A.BITNET
jbn@glacier.STANFORD.EDU (John B. Nagle) (05/18/88)
Wirth's papers on why Wirth's languages are so great should be viewed
with suspicion. Read his "Experience with the Programming Language Modula",
(Software Practice and Experience, circa 1978) which refers to Modula I.
He sounds like a reviewer, but doesn't find any of the problems. But
as soon as Modula II came out, he started talking of Modula I as an
"experiment". That's not what he said when he was pushing Modula I.
As one of a group who wrote an entire operating system in Modula I,
I'm very aware of the limitations of that language.
In each of Wirth's languages there is some tragic flaw, something
that drives users straight up the walls. What will it be in Oberon?
John Naglefreek@uva.UUCP (Freek Wiedijk) (05/19/88)
In article <17451@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > In each of Wirth's languages there is some tragic flaw, something >that drives users straight up the walls. What will it be in Oberon? What was the flaw in Modula-2 [in your opinion :-)]? What bothers me about Oberon: In Modula-2 it is possible to do your own memory-management by implementing module Storage yourself. What I would like is the possibility to taylor the garbage collection that is present in Oberon in an analogous way, but I don't think that that is possible. Comments? > John Nagle -- Freek Wiedijk <the pistol major> UUCP: uunet!mcvax!uva!freek #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**
biagioni@cs.unc.EDU (Edoardo Biagioni) (05/19/88)
In article <INFO-M2%88051808492544@DB0TUI11> you write: >Hello, > >I'm currently reading the logfile of the March discussions of this list. >It contains many articles about a Wirth paper called "From Modula to >Oberon". Does anyone of you has this paper online? If so, could you >please send it to me? Or is this a real sheet of paper, unable to be >e-mailed? In case of a real paper, in what journal/magazine/whateverelse >has it been published? > >Thanks in advance, >Michael >HPA111@DE0HRZ1A.BITNET Here's what was posted to the net: From thorin!mcnc!gatech!bbn!rochester!crowl Fri Feb 26 18:12:49 EST 1988 Article 129 of comp.lang.modula2: Path: thorin!mcnc!gatech!bbn!rochester!crowl >From: crowl@cs.rochester.edu (Lawrence Crowl) Newsgroups: comp.lang.modula2,comp.lang.misc Subject: From Modula to Oberon Message-ID: <7161@sol.ARPA> Date: 26 Feb 88 16:03:18 GMT Reply-To: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 584 Xref: thorin comp.lang.modula2:129 comp.lang.misc:244 Oberon is a new language designed by Niklaus Wirth. It is a refinement of Modula-2. The remainder of this article is the LaTeX form of an article which appeared in ASCII form on BIX. Enjoy. -------------------------------------------------------------------------- \documentstyle[11pt]{article} % % margin settings % \oddsidemargin 0.5in % Left margin on odd-numbered pages. \evensidemargin 0in % Left margin on even-numbered pages. \textwidth 6in \textheight 8.5in \topmargin 0.25in \headheight 0pt \headsep 0pt \footheight 12pt \footskip 30pt % % paragraph settings % \parskip 4pt plus 1.5pt minus 1.5pt \clubpenalty 500 \widowpenalty 500 \displaywidowpenalty=500 \begin{document} \title{From Modula to Oberon} \author{N. Wirth} \date{Tuesday 23 February 1988} \maketitle \begin{abstract} The programming language Oberon is the result of a concentrated effort increase the power of Modula-2 and simultaneously to reduce its complexity. Several features were eliminated, and a few were added in order to increase the expressive power and flexibility of the language. This paper describes and motivates the changes. The language is defined in a concise report. \vspace{0.25in} \noindent BIX oberon/long.messages \#11, from frode, 21774 chars, Tue Feb 23 20:43:46 1988. \break TITLE: Oberon Language Article, (c) ETH-ZENTRUM, SWITZERLAND \end{abstract} \section*{Introduction} The programming language Oberon evolved from a project whose goal was the design of a modern, flexible and efficient operating system for a single-user workstation. A principal guideline was to concentrate on properties that are genuinely essential and --- as a consequence --- to omit ephemeral issues. It is the best way to keep a system in hand, to make it understandable, explicable, reliable and efficiently implementable. Initially, it was planned to express the system in Modula-2 [1], as that language supports the notion of modular design quite effectively, and because an operating system has to be designed in terms of separately compilable parts with conscientiously chosen interfaces. In fact, an operating system should be no more than a set of basic modules, and the design of an application must be considered as a goal-oriented extension of that basic set: Programming is always {\em extending} a given system. Whereas modern languages, such as Modula, support the notion of extensibility in the procedural realm, the notion is less well established in the domain of data types. Modula in particular does not allow the definition of new data types as extensions of other, programmer-defined types in an adequate manner. An additional feature was called for, thereby giving rise to an extension of Modula. The concept of the planned operating system also called for a highly dynamic, centralized storage management relying on the technique of garbage collection. Although Modula does not prevent the incorporation of a garbage collector in principle, its variant record feature constitutes a genuine obstacle. As the new facility for extending types would make the variant record feature superfluous, the removal of this stumbling block was a logical decision. This step, however gave rise to a restriction (subset) of Modula. It soon became clear that the rule to concentrate on the essential and to eliminate inessential should not only be applied to the design of the new system, but equally stringently to the language in which the system is formulated. The application of the principle thus led from Modula to a new language. The adjective new, however, has to be understood in proper context: Oberon evolved from Modula by very few additions and several subtractions. In relying on evolution rather than revolution we remain in the tradition of a long development that led from Algol to Pascal, then to Modula-2, and eventually to Oberon. The common trait of these languages are their procedural rather than functional model, and the strict typing of data. More fundamental even is perhaps the idea of abstraction: the language must be defined in terms of mathematical, abstract concepts without reference to any computing mechanism. Only if a language satisfies this criterion can it be called ``higher-level''. No syntactic coasting whatsoever can earn a language this attribute alone. The definition of a language must be coherent and concise. This can only be achieved by a careful choice of the underlying abstractions an appropriate structure combining them. The language manual must be reasonably short, avoiding the explanation of individual cases derivable from the general rules. The power of a formalism must not be measured by the length of its description. To the contrary, an overly lengthy definition is a sure symptom of inadequacy. In this respect, not complexity but simplicity must be the goal. In spite of its brevity, a description must be complete. Completeness is to be achieved within the framework of the chosen abstractions. Limitations imposed by particular implementations do not belong to a language definition proper. Examples of such restrictions are the maximum values of numbers, rounding and truncation errors in arithmetic, and actions taken when a program violates the stated rules. It should not be necessary to supplement a language definition with voluminous standards document to cover ``unforeseen'' cases. But neither should a programming language be a mathematical theory only. It must be practical tool. This imposes certain limits on the terseness of the formalism. Several features of Oberon are superfluous from a purely theoretical point of view. They are nevertheless retained for practical reasons, either for programmers' convenience or to allow for efficient code generation without the necessity of complex, ``optimizing'' pattern matching algorithms in compilers. Examples of such features are the presence of several forms of repetitive statements, and of standard procedures such as INC, DEC, and ODD. They complicate neither the language conceptually nor the compiler to any significant degree. These underlying premises must be kept in mind when comparing Oberon with other languages. Neither the language nor its defining document reach the ideal; but Oberon approximates these goals much better than its predecessors. A compiler for Oberon has been implemented for the NS32000 processor family and is embedded in the Oberon operating environment. The following data provide an estimate of the simplicity and efficiency of the implementation, and readers are encouraged to compare them with implementations of other languages. (Measurements with 10 MHz NS32032). \begin{center} \begin{tabular}{lrrrr} \hline &\multicolumn{2}{c}{length of} &\multicolumn{1}{c}{length of} &\multicolumn{1}{c}{time of self}\\ &\multicolumn{2}{c}{source program} &\multicolumn{1}{c}{compiled code} &\multicolumn{1}{c}{compilation}\\ \hline &lines &characters &bytes &seconds\\ \hline Parser&1116&3671&99928&11.53\\ Scanner&346&9863&3388&3.80\\ Import/Export&514&18386&4668&5.25\\ Code generator&19636&5901&21636&21.02\\ Total&3939&130869&39620&41.60\\ \end{tabular} \end{center} Subsequently, we present a brief introduction to Oberon assuming familiarity with Modula (or Pascal), concentrating on the added features and listing the eliminated ones. In order to be able to ``start with a clean table'', the latter are taken first. \section*{Features omitted from Modula} \subsection*{Data types} Variant records are eliminated, because they constitute a genuine difficulty for the implementation of a reliable storage management system based on automatic garbage collection. The functionality of variant records is preserved by the introduction of extensible data types. Opaque types cater to the concept of the abstract data type and information hiding. They are eliminated because again the concept is covered by the new facility of extended record types. Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend enumeration types would have to be introduced, or they would have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations had led to a pompous style that contributed not to program clarity, but rather to verbosity. In connection with import and export, enumerations gave rise to the exceptional rule that import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor. Subrange types were introduced in Pascal (and adopted in Modula) for two reasons: (1) to indicate that a variable accepts a limited range of values of the base type and allow a compiler to generate appropriate guards for assignments, and (2) to allow a compiler to allocate the minimal storage space needed to store values of the indicated subrange. This appeared desirable in connection with packed records. Very few implementations have taken advantage of this space saving facility, because additional compiler complexity is very considerable. Reason 1 alone, however, did not appear to provide sufficient justification to retain the subrange facility in Oberon. With the absence of enumeration and subrange types, the general possibility to define set types based on given element types appeared as redundant. Instead, a single, basic type SET is introduced, whose values are sets of integers from 0 to an implementation-defined maximum. The basic type CARDINAL had been introduced in Modula-2 in order to allow address arithmetic with values from 0 to $2^{16}$ on 16-bit computers. With the prevalence of 32-bit addresses in modern processors, the need for unsigned arithmetic has practically vanished, and therefore the type CARDINAL has been eliminated. With it, the bothersome incompatibilities of operands of types CARDINAL and INTEGER have disappeared. The notion of a definable index type of arrays has also been abandoned: All indecies are by default integers. Furthermore, the lower bound is fixed to 0; array declarations specify a number of elements (length) rather than a pair of bounds. This break with a long standing tradition since Algol 60 demonstrates the principle of eliminating the inessential most clearly. The specification of an arbitrary lower bound provides no expressive power at all, but it introduces a non-negligible amount of hidden, computational effort. (Only in the case of static declarations can it be delegated to the compiler). \subsection*{Modules and import/export rules} Experience with Modula over the last eight years has shown that local modules were rarely used. The additional complexity of the compiler required to handle them, and the additional complications in the visibility rules of the language definition appear not to justify local modules. The qualification of an imported object's identifier x by the exporting module's name M, viz. M.x can be circumvented in Modula by the use of the import clause FROM M IMPORT x. This facility has also been discarded. Experience in programming systems involving many modules has taught that the explicit qualification of each occurrence of x is actually preferable. A simplification of the compiler is a welcome side-effect. The dual role of the main module in Modula is conceptually confusing. It constitutes a module in the sense of a package of data and procedures enclosed by a scope of visibility, and at the same time it constitutes a single procedure called the main program. Within the Oberon system, the notion of a main program has vanished. Instead, the system allows the user to activate any (exported, parameterless) procedure (called a command). Hence, the language excludes modules without explicit definition parts, and every module is defined in terms of a definition part and an implementation part (not definition module and implementation module). \subsection*{Statements} The with statement has been discarded. Like in the case of exported identifiers, the explicit qualification of field identifiers is to be preferred. The elimination of the for statement constitutes a break with another long standing tradition. The baroque mechanism in Algol 60's for statement had been trimmed considerably in Pascal (and Modula). Its marginal value in practice has led to its absence in Oberon. \subsection*{Low-level facilities} Modula-2 makes access to machine-specific facilities possible trough low-level constructs, such as the data types ADDRESS and WORD, absolute addressing of variables, and type casting functions. Most of them are packaged in a module called SYSTEM. The features were supposed to rarely used and easily visible trough the presence of SYSTEM in a module's import list. Experience has revealed, however, that a significant number of programmers import this module quite indiscriminately. A particulary seducing trap are Modula's type transfer functions. It appears preferable to drop the pretense of portability of programs that import a ``standard'', yet system-specific module. Both the module SYSTEM and the type transfer functions are eliminated, and with them also the types ADDRESS and WORD. Individual implementors are free to provide system-dependent modules, but they do not belong to the general language definition. Their use then declares a program to be patently implementation-specific, and thereby non-portable. \subsection*{Concurrency} The system Oberon does not require any language facilities for expressing concurrent processes. The pertinent, rudimentary features of Modula, in particular the coroutine, were therefore not retained. This exclusion is merely a reflection of our actual needs within the concrete project, but not on the general relevance of concurrency in programming. \section*{Features introduced in Oberon} \subsection*{Type extension} The most important addition is the facility of extended record types. It permits the construction of new types on the basis of existing types, and establishing a certain degree of compatibility between the names of the new and old types. Assuming a given type \begin{verbatim} T = RECORD x, y: INTEGER END \end{verbatim} extensions may be defined which contain certain fields in addition to the existing ones. For example \begin{verbatim} T0 = RECORD (T) z: REAL END; T1 = RECORD (T) w: LONGREAL END; \end{verbatim} define types with fields x, y, z and x, y, w respectively. We define a type declared by \begin{verbatim} T' = RECORD (T) <field definitions> END \end{verbatim} to be a (direct) extension of T, and conversely T to be the (direct) base type of T'. Extended types may be extended again, giving rise to the following definitions: A type T' is an extension of T, if T' = T or T' is a direct extension of an extension of T. Conversely, T is a base of T', if T = T' or T is the direct base type of a base type of T'. We denote this relationship by T' {\tt =>} T. The rule of assignment compatibility states that values of an extended type are assignable to variables of their base types. For example, a record of type T0 can be assigned to a variable of the base type T. This assignment involves the fields x and y only, and in fact constitutes a projection of the value onto the space spanned by the base type. It is important that an extended type may be declared in a module that imports the base type. In fact, this is probably the normal case. This concept of extensible data type gains importance when extended to pointers. It is appropriate to say that a pointer type P' bound to T' extends a pointer type P, if P is bound to a base type T of T', and to extend the assignment rule to cover this case. It is now possible to form structures whose nodes are of different types, i.e. inhomogenious data structures. The inhomogeneity is automatically (and most sensibly) bounded by the fact that the nodes are linked by pointers of a common base type. Typically, the pointer fields establishing the structure are contained in the base type T, and the procedures manipulating the structure are defined in the same (base) module as T. Individual extensions (variants) are defined in client modules together with procedures operating on nodes of the extended type. This scheme is in full accordance with the notion of system extensibility: new modules defining new extensions may be added to a system without requiring a change of the base modules, not even their recompilation. As access to an individual node via a pointer bound to a base type provides a projected view of the node data only, a facility to widen the view is necessary. It depends on the possibility to determine the actual type of the referenced node. This is achieved by a type test, a Boolean expression of the form \begin{verbatim} t IS T' (or p IS P') \end{verbatim} If the test is affirmative, an assignment t' := t (t' of type T') or p' := p (p' of type P') should be possible. The static view of types, however, prohibits this. Note that both assignments violate the rule of assignment compatibility. The desired statement is made possible by providing a type guard of the form \begin{verbatim} t' := t(T) (p' := p(P)) \end{verbatim} and by the same token access to the field z of a T0 (see previous examples) is made possible by a type guard in the designator t(T0).z. Here the guard asserts that t is (currently) of type T0. The declaration of extended record types, the type test, and the type guard are the only additional features introduced in this context. A more extensive discussion is provided in [2]. The concept is very similar to the class notion of Simula 67 [3], Smalltalk [4], and others. Differences lie in the fact that the class facility stipulates that all procedures applicable to objects of the class are defined together with the data declaration. It is awkward to be obliged to define a new class solely because a method (procedure) has been added or changed. In Oberon, procedure (method) types rather than methods are connected with objects in the program text. The binding of actual methods (specific procedures) to objects (instances) is delayed until the program is executed. In Smalltalk, the compatibility rules between a class and its subclasses are confined to pointers, thereby intertwining the concept of access method and data type in an undesirable way. Here, the relationship between a type an its extensions is based on the established mathematical concept of projection. In Modula, it is possible to declare a pointer type within an implementation module, and to export it as an opaque type by listing the same identifier in the corresponding definition module. The net effect is that the type is exported whereby its associated binding remains hidden (invisible to clients). In Oberon, this facility is generalized in the following way: Let a record type be defined in a certain implementation part, for example: \begin{verbatim} Viewer = RECORD width, height: INTEGER; x, y: INTEGER END \end{verbatim} In the corresponding definition part, a partial definition of the same type may be specified, for example \begin{verbatim} Viewer = RECORD width, height: INTEGER END \end{verbatim} with the effect that a partial view --- a public projection --- is visible to clients. In client modules as well as in the implementation part it is possible to define extensions of the base type (e.g. TextViewers or GraphViewers). \subsection*{Type inclusion} Modern processors feature arithmetic operations on several number formats. It is desirable to have all these formats reflected in the language as basic types. Oberon features five of them: \begin{verbatim} LONGINT, INTEGER, SHORTINT(integer types) LONGREAL, REAL(real types) \end{verbatim} With the proliferation of basic types, a relaxation of compatibility rules between them becomes almost mandatory. (Note that in Modula the arithmetic types INTEGER, CARDINAL and REAL are uncompatible). To this end, the notion of type inclusion is introduced: a type T includes a type T', if the values of T' are also values of type T. Oberon postulates the following hierarchy: \begin{verbatim} LONGREAL > REAL > LONGINT > INTEGER > SHORTINT \end{verbatim} [Note that ``{\tt >}'' should be replaced by the appropriate mathematical sign. Limitation of type-in..] The assignment rule is relaxed accordingly: A value of type T' can be assigned to a variable of type T, if T' is included in T (if T' extends T), i.e. if T {\tt >} T' or T' {\tt =>} T. In this respect, we return to (and extend) the flexibility of Algol 60. For example, given variables \begin{verbatim} i: INTEGER; k: LONGINT; x: REAL \end{verbatim} the assignments \begin{verbatim} k:=i; x:=k; x:=1; k:=k+1; x := x*10 + i \end{verbatim} are confirming to the rules, where the assignments \begin{verbatim} i:=k; k:=x \end{verbatim} are not acceptable. Finally, it is worth noting that the various arithmetic types represent a limited set of subrange types. The multi-dimensional open array and the closure statement (in symmetry to a module's initialization body) are the remaining facilities of Oberon not present in Modula. \section*{Summary} The language Oberon has evolved from Modula-2 and incorporates the experiences of many years of programming in Modula. A significant number of features have been eliminated. They appear to have contributed more to language and compiler complexity than to genuine power and flexibility of expression. A small number of features have been added, the most significant one being the concept of type extension. The evolution of a new language that is smaller, yet more powerful than its ancestor is contrary to common practices and trends, but has inestimable advantages. Apart from simpler compilers, it results in a concise definition document [5], and indispensible prerequisite for any tool that must serve in the construction of sophisticated and reliable systems. \section*{Acknowledgement} It is impossible to explicitly acknowledge all contributions of ideas that ultimately simmered down to what is now Oberon. Most came from the use or study of existing languages, such as Modula-2, Ada, Smalltalk, C++ and Cedar, which often though us how not to do it. Of particular value was the contribution of Oberon's first user, J. Gutknecht. The author is grateful for his insistence on the elimination of deadwood and on basing the remaining features on a sound mathematical foundation. \section*{References} \noindent 1. N. Wirth. Programming in Modula-2. Springer-Verlag, 1982. \noindent 2. N. Wirth. Type Extensions. ACM Trans. on Prog. Languages and Systems (to appear) \noindent 3. G. Birtwistle, et al. Simula Begin. Auervach, 1973. \noindent 4. A. Goldberg, D. Robson. Smalltalk-80: The language and its implementation. Addison-Wesley, 1983. \noindent 5. N. Wirth. The Programming language Oberon (language definition document) \end{document} -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627
jbn@glacier.STANFORD.EDU (John B. Nagle) (05/19/88)
Wirth writes: >In relying on evolution rather than revolution we remain in the >tradition of a long development that led from Algol to >Pascal, then to Modula-2, and eventually to Oberon. Wirth is rewriting history here. Between Pascal and Modula 2 was Modula 1, or simply Modula, an embarassment he now calls "an experiment", but in its day was promoted as a successor to Pascal. John Nagle
pattis@june.cs.washington.edu (Richard Pattis) (05/19/88)
Wirth has an article in the April'88 ToPLaS on "Type Extensions".
uday@mips.COM (Robert Redford) (05/19/88)
In article <17451@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > In each of Wirth's languages there is some tragic flaw, something > that drives users straight up the walls. What will it be in Oberon? > Is there any language that does not have a tragic flaw? ..Uday
jbn@glacier.STANFORD.EDU (John B. Nagle) (05/20/88)
In article <2220@gumby.mips.COM> uday@mips.COM (Robert Redford) writes: > > Is there any language that does not have a tragic flaw? Wirth's designs very restrictive languages. He tries to compel people to program in ways that he thinks proper. As he says in the introduction to the original Pascal report, "Along with this dissatisfaction (with previous languages) goes my conviction that the language in which the student is taught to express his ideas profoundly influences his habits of thought and invention, and the disorder governing these languages directly imposes itself onto the programming style of the students." Thus, in a Wirth language, there is ideally only one way to do something, the right way, and many marginally useful things one is forbidden to do. Any flaw in that right way is thus magnified, for there is not likely to be an easy way to escape the problem. Thus such flaws become tragic rather than cosmetic. In C, which in many ways is inferior to Pascal or Modula (either number) in elegance and precision, not to mention safety, one does not often encounter this problem. C has many flaws, but there are usually ways around them. Thus, a major programming effort mounted in C is not likely to run into an unyielding wall of the sort one occasionally encounters in a Wirth language. For this reason, it is important to know, before starting any major effort in a Wirth language, where the unyielding walls that can kill projects lie. Thus it is a good exercise to search any new Wirth language for such flaws early in its life, and to make those walls well known, so that the design constraints they impose can be well understood before it is too late. John Nagle
rcd@ico.ISC.COM (Dick Dunn) (05/21/88)
John Nagle: > In each of Wirth's languages there is some tragic flaw, something > that drives users straight up the walls. What will it be in Oberon? The lack of a counted loop ("for" statement) gets my nomination for tragic flaw. With most imperative languages in the past 30+ years having a counted loop, you'd think it would have proved its merit. Even languages that don't have it (like C) have evolved paradigms for it that are accepted among the language's users. [That is, most C programmers write in the form "for (i=0; i<n; i++)" without a second thought; that way they don't worry about the various off-by-1's like starting at 1 or running to <=n...] -- Dick Dunn UUCP: {ncar,cbosgd,nbires}!ico!rcd (303)449-2870 ...Never attribute to malice what can be adequately explained by stupidity.
BOTCHAIR@UOGUELPH.BITNET (Alex Bewley) (05/21/88)
As far a flaws and impositions of 'good' programming...
Pascal was oriented at students. It was designed to impose structured and
coherent programming techniques on the student. I found that learning pascal
early in my programming career helped me enormously, and now I can move
to any other language with relative ease and write 'good' code. Whereas, had
I learned C I would have been bred with a more cryptic sense of structure.
I use Modula-2 extensively and have not found any really tragic flaws that
are major hangups.
Alexsbrunnoc@eagle.ulowell.edu (Sean Brunnock) (05/23/88)
From article <5260@ico.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn): > John Nagle: >> In each of Wirth's languages there is some tragic flaw, something >> that drives users straight up the walls. What will it be in Oberon? > The lack of a counted loop ("for" statement) gets my nomination for tragic > flaw. I find this curious. I read Hillis' thesis recently (The Connection Machine) and he states that with a massively parallel computer such as his, there is no need for a for loop. Operations are done on entire sets of numbers or other data at a time. I have not read Wirth's paper closely (but I shall soon). Do you think Wirth had massively parallel machines in mind when writing Oberon? As far as I know there is only one language, MultiLISP, that is available for the Connection Machine. Sean Brunnock
windley@iris.ucdavis.edu (Phil Windley) (05/23/88)
From article <5260@ico.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn): > John Nagle: >> In each of Wirth's languages there is some tragic flaw, something >> that drives users straight up the walls. What will it be in Oberon? > The lack of a counted loop ("for" statement) gets my nomination for tragic > flaw. Until Oberon, I was convinced that modern languages were moving in the OPPOSITE direction. For loops are a limited form of generator ala ICON and of course, with a closure you can do some very interesting things with generators. If Wirth is going to say generators are a bankrupt construct that he is going to have to do more than include one cryptic sentence in a language description to convince me. Phil Windley | windley@iris.ucdavis.edu Robotics Research Lab | ucbvax!ucdavis!iris!windley University of California, Davis |
ian@mucs.UX.CS.MAN.AC.UK (Ian Cottam) (05/24/88)
In article <17453@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > > Wirth writes: >>In relying on evolution rather than revolution we remain in the >>tradition of a long development that led from Algol to >>Pascal, then to Modula-2, and eventually to Oberon. > > Wirth is rewriting history here. Between Pascal and Modula 2 was >Modula 1, or simply Modula, an embarassment he now calls "an experiment", >but in its day was promoted as a successor to Pascal. > John Nagle [Hello John, I think we met about 10 years ago when I was working on the] [Modula-1 system at York that FACC wrote KSOS in.] Whilst agreeing with most things John posts, I think he is being a little hard on Wirth. Having got my copy of "Modula: a language for modular multiprogramming, SP&E, Vol 7, 3-35, 1977" off the shelf, I cannot see (nor could I remember) any claim that Modula-1 was a successor to Pascal. Some quotes: "... intended primarily for programming dedicated computer systems, including process control..." "...Modula is experimental. The presence or absence of certain facilities is still subject to controversy." Perhaps you meant that someone else, other than Wirth, promoted it as a successor to Pascal? On days when I am wearing my hair-shirt, I look back on Modula-1 with some affection! ian@ux.cs.man.ac.uk
dragon@trwspf.TRW.COM (Roger Vossler) (05/28/88)
In article <3957@mucs.UX.CS.MAN.AC.UK> ian@mucs.UUCP (Ian Cottam) writes:
*Whilst agreeing with most things John posts, I think he is being a little
*hard on Wirth. Having got my copy of "Modula: a language for modular
*multiprogramming, SP&E, Vol 7, 3-35, 1977" off the shelf, I cannot see
*(nor could I remember) any claim that Modula-1 was a successor to Pascal.
*Some quotes:
*
* "... intended primarily for programming dedicated computer
* systems, including process control..."
*
* "...Modula is experimental. The presence or absence of certain
* facilities is still subject to controversy."
*
*Perhaps you meant that someone else, other than Wirth, promoted it as a
*successor to Pascal?
*
*On days when I am wearing my hair-shirt, I look back on Modula-1 with some
*affection!
So do we! During 1977, we were getting a distributed computing research
project off the ground and chose to do our work in Concurrent Pascal.
Per Brinch Hansen was local at the time and was a consultant to my
project. We took a long look at Modula and decided against it at that
time because it *WAS* an experimental language. As such, we were not
able to obtain a copy of either the compiler nor any source code with
which to work from ETH Zurich.
During 1980, we were having problems with Concurrent Pascal and I
made a very dumb mistake by ignoring Modula-2 when it was announced.
I simply assumed that it was more of the same thing, new and improved.
Two years later (December 1982), I finally got around to looking at
Modula-2 in detail, learning in the process that it fixed most of the
problems we were having with the Concurrent Pascal technology. When I
realized the magnitude of my error, we promptly made the switch to
Modula-2 and have lived happily ever after.
--
-- Roger Vossler
TRW, Bldg O2-1395, One Space Park, Redondo Beach, CA 90278
BIX: rvossler UseNet: dragon@trwspf.trw.com
ATT: 213.535.2804 ....!trwrb!trwspf!dragon