February 2013 - Oberon - mailman3.inf.ethz.ch

Procedure Types (was: objects and jewels)
by Chris Burrows 21 Feb '13

21 Feb '13

> -----Original Message----- > From: Frans-Pieter Vonck [mailto:fp@vonck.nl] > Sent: Thursday, 21 February 2013 3:29 AM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] objects and jewels > > I remember in the module Serial you used procedure types for writing to > the UART0. The LPC2148 has two uarts and I adpted the code in a new module > to use the other UART. Now I understand procedure types are a way to > select the desired IO device. Do I recall correctly that you rewrote > Serial to meet this flexibility? > Something like that - it is a good simple example of the usefulness of Procedure types. PutCh is a procedure variable declared in the general purpose Astrobe output module 'Out'. It is expected to write one character to an arbitrary output device and is defined as: TYPE PutCharProc* = PROCEDURE (ch: CHAR); VAR PutCh: PutCharProc; There is an Init procedure in the Out module which can be used to assign the actual procedure at runtime: PROCEDURE Init*(p: PutCharProc); BEGIN PutCh := p END Init; If the programmer wants to send all subsequent output (e.g. using Out.Int, Out.String etc) from an application to UART0 (e.g. to send to a PC via a COM port), all he has to do first is call: Out.Init(Serial.PutCh) Similarly, if he later wants to redirect all subsequent output to a Nokia-style LCD display connected to the microcontroller he just has to call: Out.Init(Display.PutCh) Regards, Chris -- Chris Burrows CFB Software http://www.astrobe.com

1 0

Re: [Oberon] objects and jewels
by Frans-Pieter Vonck 20 Feb '13

20 Feb '13

Thanks Jorg, this was the interview I remembered. However the interview mentions extention of record types, but not the introduction of procedure types. I could not find simple examples of using procedure types, probably because of the introduction of type bound procedures with Oberon-2. The original oberon system uses procedure types a lot as part of the message concept. I wonder if the concept of message handling together with the task loop can be transfered to microcontrollers. Procedure Types are supported in Oberon07. To start simple, I was thinking of something like this MODULE ExampleProcType; TYPE Led = RECORD pin, port : INTEGER; init : PROCEDURE(led : Led; Pin,Port:INTEGER) END; VAR aLed : Led; PROCEDURE init (led: Led; Pin,Port: INTEGER); (*some code *) END init; BEGIN aLed.init(aLed,1,5) END ExampleProcType. This compiles in Astrobe. But i do not know what is happening here. For instance, if I change the name of the PROCEDURE init to PROCEDURE onit the module still compiles. So it seems that the procedure type init not binds with the procedure init. Could someone explain me a little more about procedure types? Greets, Frans-Pieter > Frans-Pieter > >> I remember reading an argument of Wirth against object orientation. > However >> the object way, "myservo.atttach(9)" seems more elegant than the modular way. Did I overlook something? > > You might consider this syntax as more elegant, but basically > object-oriented programming (OOP) does not add one single new concept to traditional procedural programming (PP). Read Wirth's argumentation below. > > Whether you write in OOP "myservo.attach(9)" or write in PP > "SERVO.Attach(myservo, 9)" is the same. > > br > Jörg > > Wirth: > Many people tend to look at programming styles and languages like > religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that > was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for > this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a > new data type (called subclass) by extending a given type (the > superclass). > > It is worthwhile to note that along with the OOP paradigm came an > entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one > now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didnt actually make use of its essence later on. > > Nevertheless, I consider OOP as an aspect of programming in the large; > that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming. Static modularization is > the first step towards OOP. It is much easier to understand and master than > full OOP, its sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada). > > In a way, OOP falls short of its promises. Our ultimate goal is > extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system. > EP implies that the addition of a module is possible without any change in the existing modules. They need not even be recompiled. New modules not only > add new procedures, but more importantly also new (extended) data types. > We have demonstrated the practicality and economy of this approach with the > design of the Oberon System. > >

4 5

Re: [Oberon] objects and jewels:WITH and Messages
by Frans-Pieter Vonck 20 Feb '13

20 Feb '13

Hi Chris, thank you for the article. It is good to re-read it once a while. I understand that procedure types are a necessary feature - and a safe alternative for Function overloading. Still, the WITH statement is abandoned in Oberon07. Now what does that mean for object orientation. And is it still possible to port the Oberon System to the ARM using Oberon07. Or, a little more humble, can I send messages to my Led? If found this text "MESSAGE RECORDS Type-bound procedures are one way to implement messages. Another way is to take the phrase "sending a message" literally and to view a message as a packet of data that is sent to an object. This requires message records of various kinds and lengths and a handler per object that accepts all these message records. Type-extension provides these two mechanisms. Messages are extensible records and the handler is a procedure which takes a message as a parameter and interprets it according to the dynamic type of the message. [..] ( a "BlinkaLed" message Handler) PROCEDURE HandleLed (f: led; VAR m: Message); BEGIN WITH m(OffMsg) DO ...switch led of ... | m(OnMsg) DO ... switch led on ... | m(BlinkMsg) DO ... blink led with x miliSeconds ... ELSE (* ignore the message *) END END HandleRect; source: http://www.statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.OOP.h… >> -----Original Message----- >> From: Frans-Pieter Vonck [mailto:fp@vonck.nl] >> Sent: Wednesday, 20 February 2013 3:47 AM >> To: oberon(a)lists.inf.ethz.ch >> Subject: Re: [Oberon] objects and jewels >> >> this was the interview I remembered. However the interview mentions extention of record types, but not the introduction of procedure types. >> > > That was most likely because procedure types had been around for many years > when that article was written. They were introduced in Modula-2 at the beginning of the 1980's: > > "An uncontroversial, fairly straight-forward, and most essential innovation > was the procedure type, also adopted from Mesa. In a restricted form it had > been present also in Pascal, even ALGOL, namely in the form of parametric procedures. Hence, the concept needed only to be generalized, i.e. made applicable to parameters and variables. In respect to Pascal (and ALGOL), the mistake of incomplete parameter specification was amended, making the use of procedure types type-safe. This is an apparently minor, but in reality most essential point, because a type-consistency checking system is > worthless if it contains loopholes." > > Ref: "Modula-2 and Oberon" Niklaus Wirth. Paper submitted to HOPL-3, June 2005: > > http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf > > Regards, > > Chris Burrows > CFB Software > http://www.cfbsoftware.com > > > > > > > >

1 0

Re: [Oberon] [Fwd: RE: objects and jewels]
by Frans-Pieter Vonck 20 Feb '13

20 Feb '13

Hi Jan, In the Oberon System the assembly code is hidden in the Kernel and SYSTEM Modules. Even hardware drivers like Serial did not use assembly directly. The processor on my simplecortex board,an developmentboard with Arduino format pinouts, has a core speed of 120 MHZ. The NS320 processor in the original Ceres system had a speed of 30 MHZ. So using importing assembly in driver modules was neither necessary in the early nineties as it is now in 2013. Getting and Putting registers is as low as I want to go. However register setting needs also to be abstracted. Therefore I advocate a driver module LED for all your fancy light effects. DEFINITION LED VAR led :RECORD pin,port:INTEGER END PROCEDURE Init(aled: Led) PROCEDURE InitSerie(LedsPort0,LedsPort1: SET) PROCEDURE SwitchOn(aled:Led); PROCEDURE SwitchOFF(aled: Led) PROCEDURE Blink*(aled:Led,mSec;INTEGER); END LED Greets, F.P. Greets, F.P. > On Tuesday 19 February 2013 22:13:01 Frans-Pieter Vonck wrote: > >> VAR led1: LED.led; >> LED.SwitchOn(led1); (Modular style) >> than with, >> led1.SwitchOn. (object style) > > How about > > mov dx, port > mov al, LedBit > or al, LedBit > out al, dx > > > -- > Met vriendelijke groeten, > > Jan Verhoeven > http://www.verhoeven272.nl >

1 0

Re: [Oberon] objects and jewels
by Frans-Pieter Vonck 19 Feb '13

19 Feb '13

>adequate explanation via minimum words. Luckily the ARMs nowadays come with plenty of memory. Greets, F.P. Greets,F.P. > This sounds interesting. > Is a 'pin' a hardware-connector-pin? > Is 'the modular way' of 'controlling a pin': > latching the corresponding outport via the corresponding native machine > code? > > This thread could be chance a to exercise Wirthian adequate explanation via > minimum words. > > > On 2/18/13, Frans-Pieter Vonck <fp(a)vonck.nl> wrote: >> Hi Oberoneurs, >> >> I try to "reverse engineer" the arduino language in Oberon07. >> In arduino speak you create an servo object like this: >> <code> >> Servo myservo; // create servo object to control a servo >> >> void setup() >> { >> myservo.attach(9); // attaches the servo on pin 9 to the servo object >> } >> </code> >> >> In oberon(07) this would become something like: >> MODULE Example >> IMPORT SERVO; >> VAR myservo : SERVO.servo; >> >> BEGIN >> SERVO.Init(myservo,9) >> END Example >> >> I remember reading an argument of Wirth against object orientation. However >> the object way, "myservo.atttach(9)" seems more elegant than the modular way. Did I overlook something? >> >> Greets, >> Frans-Pieter >> >> >> >> >> >> >> >> -- >> Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon >> >

2 1

Re: [Oberon] objects and jewels
by Les May 19 Feb '13

19 Feb '13

On 19/02/2013 13:53, Jörg wrote: > Frans-Pieter > >> I remember reading an argument of Wirth against object orientation. > However >> the object way, "myservo.atttach(9)" seems more elegant than the modular >> way. Did I overlook something? > You might consider this syntax as more elegant, but basically > object-oriented programming (OOP) does not add one single new concept to > traditional procedural programming (PP). Read Wirth's argumentation below. > > Whether you write in OOP "myservo.attach(9)" or write in PP > "SERVO.Attach(myservo, 9)" is the same. > > br > Jörg > > Wirth: > "Many people tend to look at programming styles and languages like > religions: if you belong to one, you cannot belong to others. But this > analogy is another fallacy. It is maintained for commercial reasons only. > Object-oriented programming (OOP) solidly rests on the principles and > concepts of traditional procedural programming (PP). OOP has not added a > single novel concept, but it emphasizes two concepts much more strongly that > was done with procedural programming. The fist such concept is that of the > procedure bound to a composite variable called object. (The binding of the > procedure is the justification for it being called a method). The means for > this binding is the procedure variable (or record field), available in > languages since the mid 1970s. The second concept is that of constructing a > new data type (called subclass) by extending a given type (the superclass). > > It is worthwhile to note that along with the OOP paradigm came an > entirely new terminology with the purpose of mystifying the roots of OOP. > Thus, whereas you used to be able to activate a procedure by calling it, one > now sends a message to the method. A new type is no longer built by > extending a given type, but by defining a subclass which inherits its > superclass. An interesting phenomenon is that many people learned for the > first time about the important notions of data type, of encapsulation, and > (perhaps) of information hiding when introduced to OOP. This alone would > have made the introduction to OOP worthwhile, even if one didn't actually > make use of its essence later on. > > Nevertheless, I consider OOP as an aspect of programming in the large; > that is, as an aspect that logically follows programming in the small and > requires sound knowledge of procedural programming. Static modularization is > the first step towards OOP. It is much easier to understand and master than > full OOP, it's sufficient in most cases for writing good software, and is > sadly neglected in most common languages (with the exception of Ada). > > In a way, OOP falls short of its promises. Our ultimate goal is > extensible programming (EP). By this, we mean the construction of > hierarchies of modules, each module adding new functionality to the system. > EP implies that the addition of a module is possible without any change in > the existing modules. They need not even be recompiled. New modules not only > add new procedures, but -- more importantly -- also new (extended) data types. > We have demonstrated the practicality and economy of this approach with the > design of the Oberon System." > > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon I hope everyone reads and takes note of Wirth's first two sentences. Les May

1 0

objects and jewels
by Frans-Pieter Vonck 19 Feb '13

19 Feb '13

Hi Oberoneurs, I try to "reverse engineer" the arduino language in Oberon07. In arduino speak you create an servo object like this: <code> Servo myservo; // create servo object to control a servo void setup() { myservo.attach(9); // attaches the servo on pin 9 to the servo object } </code> In oberon(07) this would become something like: MODULE Example IMPORT SERVO; VAR myservo : SERVO.servo; BEGIN SERVO.Init(myservo,9) END Example I remember reading an argument of Wirth against object orientation. However the object way, "myservo.atttach(9)" seems more elegant than the modular way. Did I overlook something? Greets, Frans-Pieter

3 2

[Component Pascal]
by Aubrey.McIntosh＠Alumni.UTexas.Net 17 Feb '13

17 Feb '13

Is this legal? FOR ix := 0 TO 2 DO INC( ix ) END; -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

6 6

Workflow problem?
by eas lab 16 Feb '13

16 Feb '13

Who remembers Turbo Pascal -- TP3 for DOS ! It didn't have the problem that ETHO has. Or am I missing something? Consider: you load FileA, which leads to loading FileB, which leads to loading FileC, which is very interesting. So you Grow FrameC, and you need to compare 12 lines near the top with 12 lines, 8 screens down. So you Copy and reposition and compare. And then you want to read exactly what was mentioned on 'that other' file, some 2 or 3 or 4 files ago. But THAT file is now covered/hidden. With TP3 you've got no problem because you've got a <stack window> of the most recent saved 'texts' -- IIRC? ETHO <popup> does NOT achieve this. It can't give you the LATEST copy of the TEXT, which is hidden. It can give you the latest copy of the FILE. Which is not what you want. linux:wily which is the public domain version of plan9:acme admits to being based on ETHO. But it pops-up the hidden FrameA, when called upon to reload it. It does NOT reload the text, which my differ from the display-text. Would it be feasible to do this in ETHO? Did I see come code in Chapter*.Text to trace through the TextFrames from the root, and list all the names of the nodes? Well obviously -- that's how it works. How then would you 'swing FrameA around to be visible'? ==Chris Glur

2 1

Hoare's original partition algorithm.
by Srinivas Nayak 15 Feb '13

15 Feb '13

Dear All, I started a check of different variants of quicksort Thought of trying to program and understand myself, what is common among all. 1. First "index of array" is pivot 2. Last "index of array"is pivot 3. Random "index of array"is pivot 4. Average of any two "elements of array"is pivot I was able to understand and derive first two versions myself. However, got stuck with third one. So problem is "3. Random "index of array"is pivot". Tried to take help of Hoare's original partition algorithm. [Algorithm 63: Partition, C. A. R. Hoare, CACM] Found that, it is written in Algol. All my attempts to convert this algorithm into C failed. :-( Everywhere in the net, I see the partition algorithms, where pivot is first index of array! Otherwise, after collecting random index of array as pivot, it has been exchanged with first index! I would like to see the original algorithm in a C like language, because, I am not able to understand the semantics of the Algol constructs that are used in the original version. Probably that is the reason why all my attempts to capture it in C failed. Another thing, is that Hoare used I and J as the output variable for partition algorithm. I will try to make a version with only one output variable so that the next recursive calls to quicksorts shall look like... void quicksort(int *a, int lb, int ub) { int p; if(lb >= ub) //here > is for array boundary check return; p=partition(a, lb, ub); quicksort(a, lb, p-1); quicksort(a, p+1, ub); } This is just for my understanding. Not trying to make an efficient version as given by Hoare. Can you please help me? My successful and unsuccessful attempts attached. ~#gcc -Wall -g quicksort1.c ~#./a.out Unsorted numbers: 6 5 5 6 8 8 6 3 8 1 Sorted numbers: 1 3 5 5 6 6 6 8 8 8 ~#gcc -Wall -g quicksort2.c ~#./a.out Unsorted numbers: 7 8 5 9 6 3 9 0 0 4 Sorted numbers: 0 0 3 4 5 6 7 8 9 9 ~#gcc -Wall -g quicksort3.c ~#./a.out Unsorted numbers: 4 9 1 2 7 7 2 6 6 1 Sorted numbers: 1 2 1 2 4 6 6 7 7 9 With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

3 2