Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
What you suggest is a way to determine the capacity from the initial value. More generally, this could also be applied to arrays (where I'd find it useful sometimes).
This may be quite useful. For example, these innocent looking declarations:
const ResultMessage: array [TWaitPIDResult] of TString = ('did not terminate with status ', 'terminated with status ', 'was teminated by signal ', 'was stopped by signal ', 'did something unexpected with status ');
now take up 10 KByte in the resulting executable.
But it would work only for the outer array (otherwise, how to index an array with elements of varying size?). This case would get smaller with reference-strings as described in my previous mail.
Implementing it might not be toohard, but I don't yet have a good idea for the syntax. Empty parentheses look strange to me. Besides, for arrays (not for strings) somehow the lower bound must be specified. Something like`...' perhaps:
var s: String (...) = 'Hi'; a: array [1 ...] of Integer = (42, 17, 99);
A bit strange at first glance (as it is something new) but it does the job. It takes the implicit length/upper bound constant from the attached value. We may add that constant to the construct, something like this:
var s: String ( const len ) = 'Hi'; a: array [1 ... const n ] of Integer = (42, 17, 99);
What I like about this is that it's (IMHO) more similar to Pascal syntax (assuming you mean `..' instead of `...').
What I don't like is that another identifier is introduced within some other declarations. Enum types do the same, and this has caused some extra work in the compiler. Since it's possible to get the upper bound as `High (s)' or `High (a)' (BP compatible feature), I think it's not necessary to introduce a new identifier in the declaration.
Why not start the thinking from what is as compatible as possible with standard Pascal techniques. There one would create an array of messages with a variation on:
CONST maxmsglgh = 30; (* kept short to minimize my typing *) maxmsgcnt = 3; (* and here also *)
TYPE msgid = 1..maxmsgcnt; (* or an enumeration *) amsg = PACKED ARRAY[1..maxmsglgh] OF char; msgs = ARRAY[1..maxmsgcnt] OF amsg;
VAR resultmsgs : msgs;
(* 1--------------1 *)
PROCEDURE initresultmsgs(VAR msggrp : msgs);
(* 2--------------2 *)
PROCEDURE initonemsg(ix : msgid; themsg : amsg);
BEGIN (* initonemsg *) msggrp[ix] := themsg; END; (* initonemsg *)
(* 2--------------2 *)
BEGIN (* initresultmsgs *) (* 123456789-123456789-123456789- *) initonemsg( 1, 'did not terminate with status '); initonemsg( 2, 'terminated with status '); initonemsg( 3, 'was teminated by signal '); END; (* initresultmsgs *)
(* 1--------------1 *)
.....
initresultmsgs(resultmsgs);
Which, once set up, is easily modified, allows the bulky initialization code to be segregated and gotten out of the way on suitable platforms after use, etc. The nuisance is that each message has a fixed length. We can fix this by modifying the type of amsg to include a length field (say lgh), and doing eventual writes with this as a parameter, such as:
write(fp, resultmsg.body[ix] : resultmsg.lgh);
which can in turn be encapsulated in a convenient:
PROCEDURE writeresult(VAR fp : text; ix : msgid; VAR msgset : msgs);
At least that is the way I would attack the job :-)
My point so far is that, with a little work, we have an easily modifiable, purely standard mechanism for doing the job. The point of any extended syntax is to ease that work, but NOT to change the eventual calls that use it. The tools you have in 10206 include strings with capacities and actual lengths. There is no need to make the end code look anything like C, but there is a need to make it clear.
So I suggest that further thought revolve around easing the creation of the above code in such a manner that the results can always be converted back into the ISO7185 compatible form, and possibly reduce silly typing errors. Pure standard Pascal is a very capable medium all by itself. Notice that all the above is easily converted to use an enumerated set of msgid to avoid the use of magic constants.
Even the generation of the suggested lgh field can be automated in the initialization procedure, by having it measure the number of trailing blanks present. That leaves the only real 7185 nuisance the necessity of typing in those blanks in the first place, and possibly the added storage space used. The gain is total portability.
Extensions are like optimization. The first rule is don't do it. The second rule is don't do it yet. The third rule is think it over again.