Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ptsfa!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.misc Subject: Re: From Modula to Oberon Message-ID: <3895@ihlpf.ATT.COM> Date: 4 Mar 88 02:49:37 GMT References: <7161@sol.ARPA> <2787@enea.se> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 137 Keywords: Enumerations, subranges, arrays, FOR, Eiffel In article <2787@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes: > >So Wirth has designed a new language. If he continues in this >direction he's going to end up with C next time :-) No chance of this happening. Wirth will never extend pointers to the point where they are as powerful as pointers in C. Read some of his eariler papers and you'll see why. >Wirth's argument for removing subranges is really short-cutting. >No one uses packing, and just guarding isn't sufficient enough, >he says in essence. Well, it is. Not the least when you remove >enumeration. If you had subranges, you could at least protect your >now integer-coded enumrates from illegal values due to assigning >from uninitiated variables. I never really agreed with this type of run-time checking (that's really what he is getting rid of), although it is somewhat useful for debugging purposes. First off, it is an awful lot of run-time overhead. Secondly, if your program is 'correct', you should not need this checking at all. Thirdly, it is not powerful enough. If an error like this *does* occur in my program, I would like to be able to trap it and take care of it, instead of the program just dying (maybe I can save some of the data, etc.). >I don't fully understand the passage on arrays. He says that indexes >are integers "by default". Does this mean you could have a character >index if you like? You could in Modula-2. And I quote (w/o permission) from section 9 (p36) of the "Programming in Modula-2" by Wirth (2nd edition): "For example, the array declaration map: ARRAY CHAR OF CARDINAL introduces an array of 128 cardinals where each element is indexed by a character value as shown by the statements map["A"] := 0; k := map["+"]." > The idea of having all arrays starting on index zero is really to >put the burden on the programmer. If Wirth really must have a fixed >lower index, he could at least have chosen one! How many of you do >often use arrays with zero as the lower bound? I do it very seldom. >And his argument about saving execution time for index computation >is truely naive. The result will just be references like: > String(char_no + 1), >just making the code more verbose and complex for no use. I've been thinking about the overhead for arbituary ranges on arrays. In the most efficient implementation, you would need three pieces of information to carry along (although what three pieces of information you keep is implementation-dependent): 1) Address of the first element of the array. 2) Address of the last element of the array. 3) Address of array element 0. [Note: there are other ways to organize this information such as 2 & 3 being the upper and lower bounds, respectively. But I think that you always need three pieces of information.] Also, '1)' must be known in order to access the array at all. In order to access an element x, you must calculate the address of the element (address := x * sizeof(type of array) + '3)'), and check to see that it falls within the bounds of '1)' and '2)'. Assuming that '1)' is a synonym (internally) for the array (and I am defining this value to be of no cost since all implementations of array indeces need this or a similar value) , this involves 1 indirect reference (to get '3)') to calculate the address of the element x, which would not be needed if the lower bound is always 0 (since '1)' and '3)' are the same address; hence, only two pieces of information are needed in this case). Also, this example shows that maximal efficiency is achieved by making the lower-bound 0 instead of 1. A proposed solution: whenever you need an array from 1..n, why don't you just declare it from 0..n?? I know that this takes slightly more memory (1 extra element), but in most circumstances it is probably worth (no pun intended :-)) it. If 1 were always the lower bound, then whenever you needed an array starting at 0 you would *always* have to add one to your index; there are no other tricks around it. BTW, I liked having arrays with variable ranges. In C, I can implement this when necessary (by playing with pointers), but this does not seem to be possible in Oberon (without always adjusting the index). >The removal of the FOR-statement is also questionable. This means >that all loops must be done with WHILE (or REPEAT?). WHILE is more >error-prone than FOR, since there are more things that the programmer >has to take care of. > And particulary in Pascal, and I guess also Modula, a certain mistake >may have disastrous consequences: > PROCEDURE A; > VAR i : integer; > PROCEDURE B; > BEGIN > FOR i := 1 TO Max DO > Something; > END; > BEGIN > FOR i := 1 TO Max DO > B; > END; >Since we forgot to declare i in B, B will be called only once. (OK, >depends on how FOR is implemented, but replace with WHILE and there is >no doubt.) Most Pascal implementions help to save you from this by >allowing an arbitrary order of the declarations, so we can desclare i >just before A's body. (How about Modula and Oberon?) This is illegal in standard Pascal! B is NOT allowed to modify i in this manner, since i is the loop variable in A. I think that Wirth is taking this out because it is not always possible at compile time to determine whether or not the 'global' loop variable is being used by the local procedure (just add a few conditionals and flags passed to B to the above example and you'll see what I mean). Since compilers don't get it right (ie, always enforce the rules of the language--something which Wirth seems to thing programming languages need), why leave it in?? Also, arbitrary order of declarations alone does not alleviate this problem. In your example, i should still be a valid var in B. You have to add the restriction the no variable (procedure, type, etc.) can be used before it is declared. >Missing in many OO-languages as Simula, Smalltalk and also Oberon. I don't think that Oberon is even *close* to being object-oriented!! So far, this discussion has been comparing Oberon to Wirth's previous languages (with little bits of other languages thrown in). In addition to this, I would like to see a discussion of what types of programs this language IS suited for, especially with respect to other languages. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_