VAR p: POINTER TO ARRAY OF REAL;where the actual size of the array is established with extra parameters to the NEW procedure.
When I first saw this I thought it was an unnecessary luxury, but I soon discovered that it's indispensable when doing anything with matrices. Here's why: when you write a matrix manipulation procedure (inversion, eigenvector calculations, etc.) the language supports the necessary open arrays as parameters, but it has no support for the temporary matrices that the procedure needs for intermediate steps in the calculation. I try to stick to standard M2 in my programming as much as possible, but for that particular application I could not find any reasonable way of doing the job without using the XDS language extension.
There is a traditional solution for ONE-dimensional arrays: declare a data type that's a pointer to the largest possible array, and then use ALLOCATE to create an array of the correct size. The point that many of us have missed - certainly I didn't realise it until I started coding some matrix applications - was that this traditional solution does not work for arrays with more than one subscript. To solve such problems and remain within the constraints of the official M2 definition, you have to go back to the old Fortran II trick of using one-dimensional arrays to simulate multi-dimensional arrays. The trick works, but I'd like to be able to claim that Modula-2 is at least as good as Fortran IV (which made the Fortran II kludge unnecessary).
Peter Peter Moylan
Not only do I not think this goes too far, I am in general agreement. Some of you may recall that I have brought this issue up before some years ago, though to no avail. My concern (matrix arithmetic) was the same at the time.
Rick Rick Sutcliffe
>At present I'm using the XDS compiler, and it has a language extension >that allows open arrays to be declared even when they're not >procedure parameters. For example, you can declare > VAR p: POINTER TO ARRAY OF REAL; >where the actual size of the array is established with extra >parameters to the NEW procedure.Like Rick, I am also in general agreement with this idea. I thought about it some times ago but (as Rick mentioned) at that time some people wre afraid "to open Pandoras box". Creating matrices with dynamic size is useful in many algorithms (the last time I had to use the Fortran II trick was with the Warshall algorithm). To open discussion fully I would like to "suggest" an other idea which is close to the old Algol60 approach: Indices of array types declared within procedures (that is: within dynamic scopes) need not be constants but may be variables the value of which is known at the time of the elaboration of the type declaration (i. e. variables of the outer scope or parameters).
PROCEDURE MyMatrixOperation (VAR transient: ARRAY OF ARRAY OF SomeType; max: CARDINAL); VAR auxMatrix, auxMatrix2: ARRAY [1 .. max, 1 .. max] OF SomeType; BEGIN : :I see two advantages in this concept:
I would like to here some opinions on both ideas. A first question concerning the following example:
VAR m1, m2: POINTER TO ARRAY OF ARRAY OF REAL; BEGIN : : m1 := m2; : m1^ := m2^;Is either of these legal?
Albert asked -
> I would like to here some opinions on both ideas. A first question > concerning the following example: > VAR > m1, m2: POINTER TO ARRAY OF ARRAY OF REAL; > BEGIN > : > : > m1 := m2; > : > m1^ := m2^; > Is either of these legal?Given the use of variable sized objects I don't see why they should not both be legal!
Hello folks, after a rather long silence.
How can I be as nice as possible about this? Once again WG13 seems to be rushing off down a side issue in a fragmented way. Not that the idea is a bad one, it is just that the "devil is in the detail" as the saying goes.
Of course Keith is right, both of the above assignements are easy to implement. The question is --- how can such a thing be useful in the absence of other language features? In particular there must be suitable overloading of the HIGH function, which at the moment only applies to to open array params. Thus a sensible person would have to say ...
IF (HIGH(m1) = HIGH(m2)) AND (HIGH(m1) = HIGH(m2)) THEN m1^ := m2^; ELSE ... Or is that HIGH(m1^) ? :-)If I personally had to nominate my favourite missing data structure from Modula, I would nominate one-dimensional arrays with automatic resizing. For more details, see "A new type-constructor for modular languages" available at http://www.dstc.qut.edu.au/~gough/publications.html
Best wishes to all
>Given the use of variable sized objects I don't see why they should not >both be legal! Perhaps, I should have made the example a bit more explicit:
VAR m1, m2: POINTER TO ARRAY OF ARRAY OF REAL; BEGIN : NEW (m1, 4, 4); NEW (m2, 10, 10); : m1^ := m2^; : m1 := m2; : m1^ := m2^;The second and third assignment are ok. But I think the first assignment is illegal. Albert.
PS The implementation I suggested would avoid all these problems, as the compatibility rules defined in the standard would hold.