Dear Fyodor Tkachov!
If I understand your question correctly, you are absolutely right. We had made a similar observation
some time ago (also with the compatibility rules of string btw.) and decided to lift such
restrictions in the forthcoming Release 1.4. The following module cannot be compile in the 1.3.x
Release family, but it can be compiled in Release 1.4. (Those who participated in the Developers
Meeting can check this already.)
MODULE Test;
TYPE
T = POINTER TO ABSTRACT RECORD END;
T1 = POINTER TO RECORD (T) END;
PROCEDURE P0 (IN a: ARRAY OF T);
END P0;
PROCEDURE P1 (IN s: ARRAY 32 OF CHAR);
END P1;
PROCEDURE Test;
VAR a: ARRAY 4 OF T1; s: ARRAY 16 OF CHAR;
BEGIN
P0(a); P1(s$)
END Test;
END Test.
All the best,
Wolfgang Weck
--------------------------------------------------------------------
Dr. Wolfgang Weck
Oberon microsystems Inc.
Technoparkstrasse 1, CH-8005 Zürich
Tel: (+41 1) 445 17 51, Fax: (+41 1) 445 17 52
mailto:weck{([at]})nowhere.xy
--------------------------------------------------------------------
> -----Original Message-----
> From: ftkachov{([at]})nowhere.xy
> Sent: Monday, November 20, 2000 10:39 AM
> To: blackbox{([at]})nowhere.xy
> Cc: F.V.Tkachov
> Subject: IN open array parameters
>
>
> Hi!
>
> I think there's a glitch with formal/actual parameters rules in Component Pascal.
> The glitch is minor but
> since it causes some overhead in a computationally intensive problem,
> I'd like to point it out.
>
> I think the glitch in the language definition is that
> IN, OUT and VAR parameters are all treated as variable parameters.
>
> But if IN parameters are not allowed to be modified inside the procedure,
> I see no point in treating them as variable.
> Semantically, IN parameters seem to be intended to optimize value parameters, so
> it seems more appropriate to group IN parameters with value parameters in regard of
> compatibility rules for formal/actual parameters.
>
> ------------------
> The problem was encountered in the following setting:
>
> Suppose we have a procedure with an IN open array parameter,
> with elements of an abstract type T.
>
> I need to call the procedure several times,
> in each call the elements of the actual array parameter may be different extensions of T.
>
> I cannot directly substitute those arrays in place of the formal parameter because
> the parameters must be "array compatible". So I must either define my actual arrays
> to have elements of the abstract type T (which requires pesky
> type tests in other parts of the algorithm),
> or define a special ARRAY OF T, explicitly copy my arrays into it, and use it as
> the actual parameter.
> (Then I have to pay attention to the length of T as my arrays may vary in length.)
>
> If I drop IN, the parameter becomes value,
> and then I just substitute the actual arrays in place of the formal parameter
> and everything works -- except that the array is copied, whence an overhead.
>
> One way or another, there is an overhead without any benefit.
> --------------------------------------------------------------
>
> May be I am missing something?
>
> Best,
> Fyodor Tkachov
> ---------------------------
> Russian Academy of Sciences
>
> P.S.
> Component Pascal is still by far the best tool for my applications
> (heavy mathematics in nature, symbol manipulation in type,
> supercomputer in scale).
>
> Cheers,
> FT
> --------------------------------------------
>
> To unsubscribe from this mailing list, send a message containing the word "unsubscribe" to:
> blackbox-request{([at]})nowhere.xy>
> To get a list of valid e-mail commands and instructions on their usage, send a message
> containing the word "help" to the above address.
>
> Send any problem reports or questions related to this email list to the list owner at
> owner-blackbox{([at]})nowhere.xy--------------------------------------------
To unsubscribe from this mailing list, send a message containing the word "unsubscribe" to:
blackbox-request{([at]})nowhere.xy
To get a list of valid e-mail commands and instructions on their usage, send a message containing the word "help" to the above address.
Send any problem reports or questions related to this email list to the list owner at
owner-blackbox{([at]})nowhere.xy
Received on Mon Nov 27 2000 - 10:07:12 UTC