Re: [BLACKBOX] IN Parameters - Making the design more regular

From: [at]} <hvl>
Date: Wed, 30 Jan 2008 19:50:00 +0100

----boundary-LibPST-iamunique-103206610_-_-
Content-type: text/plain

Hi Chris,

After your latest explanations I rethought my arguments and looked a your
example(s. below):

> Consider this code:
> PROCEDURE P(x: INTEGER);
> BEGIN
> ...
> SomeOtherProcedure(x);
> ...
> (* Who knows what the value of x is? *)

In this case I cannot see a big advantage of x being an IN parameter of
procedure P because the writer of procedure P ( and consequently procedure
SomeOtherProcedure) should and hopefully does know the value of x as
he/she is the only one having been able to modify the value of the local
variable x, which means that even when by some (parallel) exterior process
the value of x in the outer scope is changed and consequently differs from
x's value in the inner scope when calling procedure SomeOtherProcedure
this procedure uses the inner value (am I right?).
The real advantage of IN parameters for me shows up when it comes to
interfaces i.e. exported procedures. Here your proposal to allow this
keyword for all variable types would indeed on one hand make the language
more "regular" as you said, on the other hand, more important I believe,
safer as the caller of an otherwise unknown procedure from an imported
module can be shure the value of x will be unaltered after procedure
execution, which certainly improves code reliability.
This already was on my mind when I objected to the proposed change,
objected because of my - obviously false - ideas of memory handling.

Your statements:

> I'm not proposing that non-structured IN parameters are handled in the
> same way
> as VAR parameters.
> That only should be the case for records and arrays. The way I have
> implemented it is that (IN xyz: CHAR) is implemented *identically* to
> (xyz: CHAR) as far as memory allocation etc. goes. The only difference
> is that xyz is subsequently subject to the same
> compile-time checks as it would be if defined as a read-only variable.

and

> The way I have implemented it should generate identical code.

look quite convincing and if this is so I happily withdraw my objections
gratefully relying on the compiler writer (which I am not).

Regards

Harro

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-103206610_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIEhpIENocmlzLFxwYXINClxwYXINCkFmdGVyIHlv
dXIgbGF0ZXN0IGV4cGxhbmF0aW9ucyBJIHJldGhvdWdodCBteSBhcmd1bWVudHMgYW5kIGxvb2tl
ZCBhIHlvdXIgIFxwYXINCmV4YW1wbGUocy4gYmVsb3cpOlxwYXINClxwYXINCj4gQ29uc2lkZXIg
dGhpcyBjb2RlOlxwYXINCj4gIFBST0NFRFVSRSBQKHg6IElOVEVHRVIpO1xwYXINCj4gQkVHSU5c
cGFyDQo+ICAgLi4uXHBhcg0KPiAgIFNvbWVPdGhlclByb2NlZHVyZSh4KTtccGFyDQo+ICAgLi4u
XHBhcg0KPiAgICgqIFdobyBrbm93cyB3aGF0IHRoZSB2YWx1ZSBvZiB4IGlzPyAqKVxwYXINClxw
YXINCkluIHRoaXMgY2FzZSBJIGNhbm5vdCBzZWUgYSBiaWcgYWR2YW50YWdlIG9mIHggYmVpbmcg
YW4gSU4gcGFyYW1ldGVyIG9mICBccGFyDQpwcm9jZWR1cmUgUCBiZWNhdXNlIHRoZSB3cml0ZXIg
b2YgcHJvY2VkdXJlIFAgKCBhbmQgY29uc2VxdWVudGx5IHByb2NlZHVyZSAgXHBhcg0KU29tZU90
aGVyUHJvY2VkdXJlKSBzaG91bGQgYW5kIGhvcGVmdWxseSBkb2VzIGtub3cgdGhlIHZhbHVlIG9m
IHggYXMgIFxwYXINCmhlL3NoZSBpcyB0aGUgb25seSBvbmUgaGF2aW5nIGJlZW4gYWJsZSB0byBt
b2RpZnkgdGhlIHZhbHVlIG9mIHRoZSBsb2NhbCAgXHBhcg0KdmFyaWFibGUgeCwgd2hpY2ggbWVh
bnMgdGhhdCBldmVuIHdoZW4gYnkgc29tZSAocGFyYWxsZWwpIGV4dGVyaW9yIHByb2Nlc3MgIFxw
YXINCnRoZSB2YWx1ZSBvZiB4IGluIHRoZSBvdXRlciBzY29wZSBpcyBjaGFuZ2VkIGFuZCBjb25z
ZXF1ZW50bHkgZGlmZmVycyBmcm9tICBccGFyDQp4J3MgdmFsdWUgaW4gdGhlIGlubmVyIHNjb3Bl
IHdoZW4gY2FsbGluZyBwcm9jZWR1cmUgU29tZU90aGVyUHJvY2VkdXJlICBccGFyDQp0aGlzIHBy
b2NlZHVyZSB1c2VzIHRoZSBpbm5lciB2YWx1ZSAoYW0gSSByaWdodD8pLlxwYXINClRoZSByZWFs
IGFkdmFudGFnZSBvZiBJTiBwYXJhbWV0ZXJzIGZvciBtZSBzaG93cyB1cCB3aGVuIGl0IGNvbWVz
IHRvICBccGFyDQppbnRlcmZhY2VzIGkuZS4gZXhwb3J0ZWQgcHJvY2VkdXJlcy4gSGVyZSB5b3Vy
IHByb3Bvc2FsIHRvIGFsbG93IHRoaXMgIFxwYXINCmtleXdvcmQgZm9yIGFsbCB2YXJpYWJsZSB0
eXBlcyB3b3VsZCBpbmRlZWQgb24gb25lIGhhbmQgbWFrZSB0aGUgbGFuZ3VhZ2UgIFxwYXINCm1v
cmUgInJlZ3VsYXIiIGFzIHlvdSBzYWlkLCBvbiB0aGUgb3RoZXIgaGFuZCwgbW9yZSBpbXBvcnRh
bnQgSSBiZWxpZXZlLCAgXHBhcg0Kc2FmZXIgYXMgdGhlIGNhbGxlciBvZiBhbiBvdGhlcndpc2Ug
dW5rbm93biBwcm9jZWR1cmUgZnJvbSBhbiBpbXBvcnRlZCAgXHBhcg0KbW9kdWxlIGNhbiBiZSBz
aHVyZSB0aGUgdmFsdWUgb2YgeCB3aWxsIGJlIHVuYWx0ZXJlZCBhZnRlciBwcm9jZWR1cmUgIFxw
YXINCmV4ZWN1dGlvbiwgd2hpY2ggY2VydGFpbmx5IGltcHJvdmVzIGNvZGUgcmVsaWFiaWxpdHku
XHBhcg0KVGhpcyBhbHJlYWR5IHdhcyBvbiBteSBtaW5kIHdoZW4gSSBvYmplY3RlZCB0byB0aGUg
cHJvcG9zZWQgY2hhbmdlLCAgXHBhcg0Kb2JqZWN0ZWQgYmVjYXVzZSBvZiBteSAtIG9idmlvdXNs
eSBmYWxzZSAtIGlkZWFzIG9mIG1lbW9yeSBoYW5kbGluZy5ccGFyDQpccGFyDQpZb3VyIHN0YXRl
bWVudHM6XHBhcg0KXHBhcg0KPiBJJ20gbm90IHByb3Bvc2luZyB0aGF0IG5vbi1zdHJ1Y3R1cmVk
IElOIHBhcmFtZXRlcnMgYXJlIGhhbmRsZWQgaW4gdGhlICBccGFyDQo+IHNhbWUgd2F5XHBhcg0K
PiBhcyBWQVIgcGFyYW1ldGVycy5ccGFyDQo+IFRoYXQgb25seSBzaG91bGQgYmUgdGhlIGNhc2Ug
Zm9yIHJlY29yZHMgYW5kIGFycmF5cy4gVGhlIHdheSBJIGhhdmVccGFyDQo+IGltcGxlbWVudGVk
IGl0IGlzIHRoYXQgICAoSU4geHl6OiBDSEFSKSBpcyBpbXBsZW1lbnRlZCAqaWRlbnRpY2FsbHkq
IHRvICBccGFyDQo+ICAgKHh5ejogQ0hBUikgYXMgZmFyIGFzIG1lbW9yeSBhbGxvY2F0aW9uIGV0
Yy4gZ29lcy4gVGhlIG9ubHkgZGlmZmVyZW5jZSAgXHBhcg0KPiBpcyB0aGF0IHh5eiBpcyBzdWJz
ZXF1ZW50bHkgc3ViamVjdCB0byB0aGUgc2FtZVxwYXINCj4gY29tcGlsZS10aW1lIGNoZWNrcyBh
cyBpdCB3b3VsZCBiZSBpZiBkZWZpbmVkIGFzIGEgcmVhZC1vbmx5IHZhcmlhYmxlLlxwYXINClxw
YXINCmFuZFxwYXINClxwYXINCj4gVGhlIHdheSBJIGhhdmUgaW1wbGVtZW50ZWQgaXQgc2hvdWxk
IGdlbmVyYXRlIGlkZW50aWNhbCBjb2RlLlxwYXINClxwYXINCmxvb2sgcXVpdGUgY29udmluY2lu
ZyBhbmQgaWYgdGhpcyBpcyBzbyBJIGhhcHBpbHkgd2l0aGRyYXcgbXkgb2JqZWN0aW9ucyAgXHBh
cg0KZ3JhdGVmdWxseSByZWx5aW5nIG9uIHRoZSBjb21waWxlciB3cml0ZXIgKHdoaWNoIEkgYW0g
bm90KS5ccGFyDQpccGFyDQpSZWdhcmRzXHBhcg0KXHBhcg0KSGFycm9ccGFyDQpccGFyDQpccGFy
DQotLS0tXHBhcg0KVG8gdW5zdWJzY3JpYmUsIHNlbmQgYSBtZXNzYWdlIHdpdGggYm9keSAiU0lH
Tk9GRiBCTEFDS0JPWCIgdG8gTElTVFNFUlZATElTVFMuT0JFUk9OLkNIfX0AAExJ6A==
----boundary-LibPST-iamunique-103206610_-_---

Received on Wed Jan 30 2008 - 19:50:00 UTC