The ModulaTor logo 7KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

Erlangen's First Independent Modula_2 Journal! Nr. 6, Jul-1994


PLSA'94 Programming Language and System Architecture Summary


From: thutt@clark.net (Taylor Hutt)
Newsgroups: comp.lang.oberon
Date: 9 Mar 1994 07:47:05 -0500
Organization: Oberon Liberation Organization, MD USA
Well, for those of you not fortunate enough to have been able to visit Zurich and attend the PLSA conference, I am offering a summary of the goings on in this, and the next few messages.

I arrived in Zurich on the morning of the first conference day. Usually the flight attendants give you some indication of where you should go, but they said nothing to this load of people (perhaps they figured that anyone taking a plane that arrives at 7:45am on a Wednesday would know what they were doing). I trundled thru the airport and finally came upon a desk with what appeared to be a dead woman checking passports. The slacker didn't even bother to give me a stamp, so I have no proof that I was ever in Zurich -- thus, you have to make a personal judgement if this message is the truth or completely fiction.

I was most disappointed by the fact that there was not even a single ice crystal in the whole city of Zurich -- Zurich was warmer than Baltimore, and Baltimore had more of that awful white stuff on the ground. (Actually, it was a pleasant surprise.)

So, after being graciously picked up at the airport by a friend, we arrived at the conference and checked in. We were handed nametags and our proceedings and eventually filtered into the main conference room. We took our seats and a few people were introduced to me. (Strangely, many of the people _already_ knew who I was, and their first question was usually something like, "Do you get paid to post messages to c.l.o?". I wonder why?)

Gutknecht was the opening speaker, and he informed us that one of the speakers had died over the previous weekend, and that Dijkstra would be talking in his place.

The conference the first day was mainly about hardware, and did not hold my interest much, I won't talk about it (plus the fact that I ended up falling asleep during almost all the talk, so I don't remember).

The end of the day was signaled by an exodus to a room in another building where drinks and snacks were served. In display cases near the back of the room, ETH had placed on display all the hardware that they had built over the past 20 years or so. There was a Russian mouse the size of a brick (literally, it was HUGE!) that was given to Wirth when he visited the creators. There were, on display, several other mice, including the Lilith, and Xerox PARC mice.

In another case were prototypes and original boards of the Lilith, the Ceres (different versions) and the Chameleon.

In other cases were a working Ceres, a working Lilith, and a final case displayed the power supplies and diskdrives (for comparison between the Lilith and the Ceres) (Wow, the Lilith supply was enormous!)

Wirth gave an interesting talk on the creation of the Lilith, where he originally requested money to build 20 computers, but was given money for only 10. By financial resourcefulness (i.e. finding cheap student labor at another school), they were able to actually build the 20 machines they wanted, using only the money for 10.

Interestingly, the Lilith went unnamed for some time -- but since it had the ability to keep people away from their families, it was named Lilith (after some lady who stole men from their wives, or something like that...)

Taylor "Film at 11" Hutt
Switzerland: Land of excellent coffee


From: thutt@clark.net (Taylor Hutt)
Newsgroups: comp.lang.oberon
Subject: Re: PLSA Summary (Day 2)
Date: Sun Mar 13 18:52:50 1994
Day two of the conference began with me being awakened by some manical robed friar swinging from the rope connected to the church bell. I am sure he was trying to awaken the entire city of Zurich with his mighty bell ringing. (Actually, it was quite nice to be wakened by this, it sure beats the electrical buzz of my alarm clock).

So, after being introduced to some type of Swiss tea (which tasted like chammomile), we were off. After taking about three steps from the apartment property, we were at a tram station, which consisted of a trash can and the most confusing automated ticket dispenser any company could have devised (perhaps AT&T designed it). Although it only had three buttons, the instructions were terrible (they said something like: 1) insert money 2) press buttons 3) take ticket. I am convinced that the entire 12th year of each Swiss child is spent mastering this machine). (As an interesting side-note, the machines will no longer take 5 Franc coins because some Russian ruble coin would also work. It turns out (so I have been told), that about 500,000 Francs were lost before they disabled the feature -- now they are fixing all the machines at a cost of 5,000,000 Francs).

So, we arrived at the conference and took our seats. The opening talk was about providing software support to making programming easier. The talk centered on the notion that the editor should be able to use spare CPU cycles and figure out what you were typing and present it to you in a more readable fashion. For example, the software should detect when you use a variable w/o declaring it first, and present it to you in a fashion that works for you.

A particularly bad example of presenting the code to a reader was 'get phone number' routine (which was either incorrect, or a small part of the entire routine).

The commentary (in a nice grey background box) said something like 'returns the number of digits in the phone number or FALSE'. (The astute reader will immediately realize that it is returning two different types).

The prototype was the following:

static bool getpn(char *str)

The presentation (visually) was pleasing, but it was quickly noted that a nice presentation does not make the code good. It was also noted that proper language design (i.e. not making the code so cryptic by language construct) also precludes the need for much of these ideas.

Personally, I felt that the presentation of the comments w/o comment delimiters, and set off from the rest of the code by a shaded background, was/is worthwhile.

The entire talk did not address one of the most common problems: code<-->comment synchronization.

There was a talk by Diomidis Spinellis (the guy that ported Perl to the PC) about a project incorporating several different programming paradigms (Imperative, Function, CSP, Logic, OOP). The system is called blueprint, and it taken from the first letters of all the paradigms which he has incorporated (Imperative, BNF, Rule-rewrite, logic programming, functional programming) (some colleague suggested 'litterbug').

He then went on to show how he was able to write an algebraic manipulation system using blueprint is only 507 lines of code (in the talk, he metioned how many lines it took in another language, but that is not in the paper....).

I believe it was Andreas Borchert who asked a question along the lines of: "What about real world problems? Does this scale up?" Diomidis said that no other tests had been done yet.

And, then we had a break and we were able to drink some more of that delicious Swiss coffee.

After the break, Clemens Szyperski (the author or Write/Edit) gave a talk on the type system of Sather 1.0 (which is quite interesting).

Then, this group of Germans began to talk about their OPAL algebraic language. This speedy compiler will churn out code at the rate of 10 lines per minute -- it takes 4.5-5 HOURS to recompile the compiler (by way of comparison: it takes 15 seconds to recompile the Oberon OS and compiler COMBINED!).

Then, we broke for lunch. Ahhh, another chance to wonder what I am eating, and to gaze at the women in the cafeteria. Then, more delicious coffee.

The first session after lunch was changed due to the death of the speaker. Dijkstra gave a talk on the role of programs in proofs (instead of proofs in programs). This was quite a treat to watch him give a (seemingly) impromptu talk in which he wrote/proved the GCD and Fibonacci sequence (incidentally, the Fib sequence is in neon lights at the main train station up along the top wall -- nobody seems to know why).

At one point during the talk, Dijkstra stopped and looked directly at Wirth and said, "Yes...., Professor Wirth?" (it was quite funny).

Then, a few moments later Dijkstra found an error in his own writings and then corrected it. He also informed us that he had abbreviated Fib() to F().

At the end of the talk, Wirth asked "Where did you get all the rabbits?" To which Dijkstra replied, "There are no rabbits!"

After all other questions were answered, Wirth quoted someone as saying "One man's constant is another man's variable", and he wanted to paraphrase that to "One man's fact is another man's rabbit."

A talk was given on a 'spreadsheet' type language for concurrent programming.

Then Michael Franz gave an interesting talk on 'steps towards a software component industry'. The talk centered on compiling source to a medium that is much denser than object code, and then generating the native code during load time. The degradation of load time performance is about 1 second per application (hardly worth complaining about), but the flexibility is great. For example, you need only compile your code once, all targets will be able to load the same 'object module' and generate the appropriate native code. Several optimizations are easier to do with this format. It is now possible to pass an object, and all of its methods across a network to another machine, on which they should execute. (Of course, with other, slower compilers, this mechanism doesn't work so well.)

The final talk of the day was about a new 'fast inter-module optimization' technique that was implemented in a new language called 'Zuse'.

That evening was the conference banquet across the river from the famous 'Needle Park'. The banquet was quite nice, and true to Swiss form, offered many different types of wine (heck, I am sure that if you ordered a glass of water, it would come with a glass of wine). Although I don't care for wine, the wine in Switzerland seemed to be much better than any of the wine I have had here (of course, buying it by the gallon (3.7 litre) probably doesn't indicate much quality).

Taylor "Tourist" Hutt
Switzerland: Land where espionage is a political crime, not a legal crime.


From: thutt@clark.net (Taylor Hutt)
Newsgroups: comp.lang.oberon
Subject: PLSA (Day 3)
Date: Mon Mar 21 02:02:25 1994
Day 3 of the PLSA conference arrived quickly, and although it was the day with the fewest scheduled sessions, it promised to be the most interesting -- for the topic was Oberon!

The day was opened, and the first session was chaired by Niklaus Wirth himself. The first session, a detailed discussion called 'Hardware and Software: The Closing Gap', was presented by Tony Hoare. If my memory serves, it was essentially about using a high level programming language to define (and possibly) implement a hardware device. [Incidentally, this seems to be the type of research that has caught Wirth's attention recently]

The second topic was 'Is Oberon as Simple as Possible'. Its essence was the idea that Oberon can be simplified by creating a 'module type' (I believe that this paper was also presented in a recent issue of ACM SigPlan Notices). I disliked this paper when I read it in SigPlan, and seeing again did nothing to dissuade my judgement of it. The author made several specious arguments of 'flaws' in Oberon, one of which is as follows.

While discussing type extension and subclassing a procedure. He defined:


  TYPE
    Class = POINTER TO ClassDesc;
    ClassDesc = RECORD
      (* blah *)
      method : PROCEDURE (self : Class; v : INTEGER);
    END;
  
  PROCEDURE Method(self : Class; v : INTEGER);
  END Method;

(* --------------- *)

  TYPE 
    SubClass = POINTER TO SubClassDesc;
    SubClassDesc = RECORD (ClassDesc) (* gurfle *) END;

  PROCEDURE OverridingMethod(self : SubClass; v : INTEGER);

  END OverridingMethod;
His complaint was that 'OverridingMethod' was not type compatible with the base's method member, and it was too tedious an operation to do something like the following:

  PROCEDURE OverridingMethod(self : Class; v : INTEGER);
  BEGIN
    WITH self:SubClass DO
    END;
  END OverridingMethod;
So, to alleviate this, he has changed the language and the semantics. The result is that to subclass a new type, you simply include a member of the base type as a variable in your new record. For example:

  TYPE
    NewSubClass = POINTER TO NewSubClassDesc;
    NewSubClassDesc = RECORD
       base : Class;
    END;
Now, 'NewSubClass' is assignment compatible to a 'Class' variable. Yikes! With this one small change, he has (sort-of) invalidated the 'has-a' relationship. I say sort of, because it 'sort-of' still is a 'has-a', but it is (more importantly), also an 'is-a'!

Another problematic point of this idea is that he has reintroduced, without using SYSTEM, the ADDRESS-OF operator (@). So much for reliable garbage collection.

Following the consumption of not-quite-enough of that delicious Swiss coffee (w/o the cream dispensed from the medicinal looking bottle), we returned for the final sessin of the day.

The first talk, called 'On the Essence of Oberon' was full of wierd mathematical symbols, and unpronouncable Greek Letters(tm). Quite obviously, we had a real theory geek in our midst (and I do not mean that in a derogatory fashion). Since I am a firm believer in the adage that 'Theory is for people who can't handle drugs, and drugs are for people who can't handle reality', I found counting the lumens emitted from the overhead projector much more enjoyable than listening to this topic (and besides, I didn't understand it).

Finally, Spiros Lalis (who did not find the need to tell us the Greek root of the word 'paradigm'), told us of his work with adding concurrency to the Oberon system. This presented paper is quite similar to the concurrent Oberon paper found on neptune.inf.ethz.ch, and I direct you to that paper if you are sincerely interested in the subject matter.

The proceedings of the conference are printed by Springer-Verlag, and their ISBN is 3-540-57840-4 or 0-387-57840-4 (two numbers are listed).

Next: The honorarium session for Prof. Wirth, and summaries.

Taylor "Mountain Grown" Hutt
Now acception donations of Swiss coffee.


The ModulaTor Forum

How to combine the ISO Modula-2 Standard Library with other, low-level terminal routines

by HJ. Trebst, email: trebst@Physik.Uni-Erlangen.de

One may think practically all programmers are keen, if not even addicted to tips and tricks. At least a multitude of magazins with such divisions and even complete books produce that impression.

I HATE TRICKS. I prefer a system so clear that the solution to problems is clear cut if not obvious. Among programming languages Modula is rather near to that ideal. Yet even with Modula there may be problems tricky enough to solve. Often the interaction between the programming language, or more accurate, the compiler, and the ideosyncrasies of the operating system becomes the source of such a problem.

Recently I developed a program which required a lot of file I/O. This application could well be handled with the ISO-M2-library. But for a sort of menu system, naturally to be driven by cursor keys, I had to read single characters without termination and without echo and use cursor positioning commands. So, despite warnings from ModulaWare, I had to mix two different worlds: ISO-M2-I/O-lib with machine specific, rather low-level I/O (Keyboard.read, TermOut.set_pos, etc., for OM2; TerminalIO.Read and TerminalIO.SetMode for MVR).

The program showed strange effects, making the cursor position to be wrong in relation to the text on the screen. I created the program at home on my PC with OM2. The goal was to transfer it later to a VAX/VMS system with MVR at work. On the VAX similar effects occurred. Key to success in a rather tough search was the possibility to insert a line monitoring device (V.24- analyzer) in the serial line between cpu and terminal. The rest of the story is simple.

The output of the program happened to comprise some text lines, of course terminated by a WriteLn, followed by escape sequences for cursor positioning, and again text. The V.24-analyzer revealed that the WriteLn produced a CR, then came the cursor positioning, followed by a LF before the next text. It was the late LF, out of the (expected) order, which produced all those strange effects. Now, in retrospective, the explanation is -nearly- as easy as the remedy.

WriteLn seems not to produce an immediate pair of CR, LF pair as I had assumed, but at first only a CR, remembering the LF for the next I/O, - I/O from the same family. But I had interfered the output stream by the cursor positioning from low-level-I/O which belongs to another family of library modules. I do not know an explanation of that behaviour nor remember a description; is that a heritage from FORTRAN with its FORMAT(1H+, ...) ? It was also not so obvious to me that OM2, a PC-based system, behaves quite similar.

The remedy, the trick I want to share with other users of OM2 and MVR is simple, for MVR on VAX/VMS as well as for OM2 on a PC: insert some additional output after the WriteLn. A simple space or even CHR(0) (ascii NUL) suffices. This makes the (high-level-) I/O to get rid of the stored LF before the inserted character, and the following cursor positioning from low-level-I/O works as expected.

[ed. note: article was received 11-Apr-1994, revised on 12-Apr-1994]

[Comment by ModulaWare engineering: the technique with the pending LF is commonly used by many system programs under VMS. ModulaWare's OM2 ISO M2 Std Lib is a portation of the VMS lib. This explains similar behaviour on another platform.]


IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication. The Editor of The ModulaTor is Günter Dotzel; he can be reached at mailto:[email deleted due to spam]


Home | Site_index | Legal | OpenVMS_compiler | Alpha_Oberon_System | ModulaTor | Bibliography | Oberon[-2]_links | Modula-2_links |

Amazon.com [3KB] [Any browser]

Books Music Video Enter keywords...


Amazon.com logo

Webdesign by www.otolo.com/webworx, 16-Dec-1998