🚀 go-pugleaf

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."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah