Re: [BLACKBOX] Read-only IN parameters for all data types

From: [at]} <CFB>
Date: Wed, 20 Feb 2008 10:11:57 +1030

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

> -----Original Message-----
> From: BlackBox [mailto:BLACKBOX{([at]})nowhere.xy
> Aubrey.McIntosh{([at]})nowhere.xy
> Sent: Wednesday, 20 February 2008 1:38 AM
> To: BLACKBOX{([at]})nowhere.xy
> Subject: Re: [BLACKBOX] Read-only IN parameters for all data
> types (Was: Mobile-device development)
>
>
> The strictness of Oberon is what defines it, in my own personal
> impressions. In the first phase, it was a nuisance, I "just wanted it
> to compile."
> But after some experience, the errors are rare, and are a great help.
>

I agree 100%. I would like to see the 'strictness' enhanced to give even
more help.

> Here, if the programmer tries to assign an "in" variable, there are
> design choices. One choice for the (language) design is that it is an
> error. The other choice is that it is just a "free" scratch variable.
>

Both choices are currently available (but only for arrays and records) in
Component Pascal. If the programmer tries to *directly* assign to an IN
parameter it is an error. The programmer can use 'value' parameters if he
wants a "free" scratch variable.

> If you pass a pointer as IN, can you change the dereferenced data?
>

Yes.

The way I see IN parameters is that they are used as value parameters with
the exception that the compiler gives an error message if you:

a) Make a direct assignment to them in the procedure where they are passed
b) Pass them on to a subsequent procedure as a VAR or OUT parameter

The precedent for the case of pointers already exists - if you pass a
pointer as a value parameter (which is only supposed to be subject to local
changes), you can in fact change the global dereferenced data. So my answer
to your question is 'Yes' - if you passed a pointer as an IN parameter you
could change the dereferenced data. What you could not do is modify the
pointer itself.

NOTE: I stated above that IN parameters are *used* as value parameters -
whether the compiler writer *implements* them as value, refererence or
whatever for efficiency reasons should not be something that the programmer
should need to be aware of - as long as the parameters *behave* as defined).

Passing a pointer as an IN parameter could be viewed as another example of
side-effects. I have not been able to think of a feasible way to protect IN
parameters from modification by side-effects as shown by Robert Campbell in
his Horrible example recently. However, a different example also shows that
IN parameters as currently implemented in BlackBox can also be modified via
side-effects. All you have to do is pass the same variable to two different
parameters in the one procedure:
 

MODULE TestGhastly;

IMPORT
  Out;

VAR
  s1, s2: ARRAY 20 OF CHAR;

PROCEDURE CapAndConcat (VAR svar: ARRAY OF CHAR; IN sin:
ARRAY OF CHAR); BEGIN
  svar[0] := CAP(svar[0]);
  svar := svar + sin;
END CapAndConcat;

PROCEDURE Do*;
BEGIN
  s1 := "wagga";
  s2 := "wagga";
  CapAndConcat(s1, s2);
  Out.String(s1);
  Out.Ln;

  s1 := "wagga";
  CapAndConcat(s1, s1);
  Out.String(s1);
  Out.Ln
END Do;
 
END TestGhastly.


Consequently, the *possibility* of side effects should not be acceptable as
an excuse for not extending the use of IN parameters to all data types.

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com/cp

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-1249685419_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS1c
cGFyDQo+IEZyb206IEJsYWNrQm94IFttYWlsdG86QkxBQ0tCT1hATElTVFMuT0JFUk9OLkNIXSBP
biBCZWhhbGYgT2YgXHBhcg0KPiBBdWJyZXkuTWNJbnRvc2hAQUxVTU5JLlVURVhBUy5ORVRccGFy
DQo+IFNlbnQ6IFdlZG5lc2RheSwgMjAgRmVicnVhcnkgMjAwOCAxOjM4IEFNXHBhcg0KPiBUbzog
QkxBQ0tCT1hATElTVFMuT0JFUk9OLkNIXHBhcg0KPiBTdWJqZWN0OiBSZTogW0JMQUNLQk9YXSBS
ZWFkLW9ubHkgSU4gcGFyYW1ldGVycyBmb3IgYWxsIGRhdGEgXHBhcg0KPiB0eXBlcyAoV2FzOiBN
b2JpbGUtZGV2aWNlIGRldmVsb3BtZW50KVxwYXINCj4gXHBhcg0KPiBccGFyDQo+IFRoZSBzdHJp
Y3RuZXNzIG9mIE9iZXJvbiBpcyB3aGF0IGRlZmluZXMgaXQsIGluIG15IG93biBwZXJzb25hbFxw
YXINCj4gaW1wcmVzc2lvbnMuICBJbiB0aGUgZmlyc3QgcGhhc2UsIGl0IHdhcyBhIG51aXNhbmNl
LCBJICJqdXN0IHdhbnRlZCBpdFxwYXINCj4gdG8gY29tcGlsZS4iXHBhcg0KPiBCdXQgYWZ0ZXIg
c29tZSBleHBlcmllbmNlLCB0aGUgZXJyb3JzIGFyZSByYXJlLCBhbmQgYXJlIGEgZ3JlYXQgaGVs
cC5ccGFyDQo+IFxwYXINClxwYXINCkkgYWdyZWUgMTAwJS4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0
aGUgJ3N0cmljdG5lc3MnIGVuaGFuY2VkIHRvIGdpdmUgZXZlblxwYXINCm1vcmUgaGVscC4gXHBh
cg0KXHBhcg0KPiBIZXJlLCBpZiB0aGUgcHJvZ3JhbW1lciB0cmllcyB0byBhc3NpZ24gYW4gImlu
IiB2YXJpYWJsZSwgdGhlcmUgYXJlXHBhcg0KPiBkZXNpZ24gY2hvaWNlcy4gIE9uZSBjaG9pY2Ug
Zm9yIHRoZSAobGFuZ3VhZ2UpIGRlc2lnbiBpcyB0aGF0IGl0IGlzIGFuXHBhcg0KPiBlcnJvci4g
IFRoZSBvdGhlciBjaG9pY2UgaXMgdGhhdCBpdCBpcyBqdXN0IGEgImZyZWUiIHNjcmF0Y2ggdmFy
aWFibGUuXHBhcg0KPiBccGFyDQpccGFyDQpCb3RoIGNob2ljZXMgYXJlIGN1cnJlbnRseSBhdmFp
bGFibGUgKGJ1dCBvbmx5IGZvciBhcnJheXMgYW5kIHJlY29yZHMpIGluXHBhcg0KQ29tcG9uZW50
IFBhc2NhbC4gSWYgdGhlIHByb2dyYW1tZXIgdHJpZXMgdG8gKmRpcmVjdGx5KiBhc3NpZ24gdG8g
YW4gSU5ccGFyDQpwYXJhbWV0ZXIgaXQgaXMgYW4gZXJyb3IuIFRoZSBwcm9ncmFtbWVyIGNhbiB1
c2UgJ3ZhbHVlJyBwYXJhbWV0ZXJzIGlmIGhlXHBhcg0Kd2FudHMgYSAiZnJlZSIgc2NyYXRjaCB2
YXJpYWJsZS5ccGFyDQpccGFyDQo+IElmIHlvdSBwYXNzIGEgcG9pbnRlciBhcyBJTiwgY2FuIHlv
dSBjaGFuZ2UgdGhlIGRlcmVmZXJlbmNlZCBkYXRhP1xwYXINCj4gXHBhcg0KXHBhcg0KWWVzLlxw
YXINClxwYXINClRoZSB3YXkgSSBzZWUgSU4gcGFyYW1ldGVycyBpcyB0aGF0IHRoZXkgYXJlIHVz
ZWQgYXMgdmFsdWUgcGFyYW1ldGVycyB3aXRoXHBhcg0KdGhlIGV4Y2VwdGlvbiB0aGF0IHRoZSBj
b21waWxlciBnaXZlcyBhbiBlcnJvciBtZXNzYWdlIGlmIHlvdTpccGFyDQpccGFyDQphKSBNYWtl
IGEgZGlyZWN0IGFzc2lnbm1lbnQgdG8gdGhlbSBpbiB0aGUgcHJvY2VkdXJlIHdoZXJlIHRoZXkg
YXJlIHBhc3NlZFxwYXINCmIpIFBhc3MgdGhlbSBvbiB0byBhIHN1YnNlcXVlbnQgcHJvY2VkdXJl
IGFzIGEgVkFSIG9yIE9VVCBwYXJhbWV0ZXJccGFyDQpccGFyDQpUaGUgcHJlY2VkZW50IGZvciB0
aGUgY2FzZSBvZiBwb2ludGVycyBhbHJlYWR5IGV4aXN0cyAtIGlmIHlvdSBwYXNzIGFccGFyDQpw
b2ludGVyIGFzIGEgdmFsdWUgcGFyYW1ldGVyICh3aGljaCBpcyBvbmx5IHN1cHBvc2VkIHRvIGJl
IHN1YmplY3QgdG8gbG9jYWxccGFyDQpjaGFuZ2VzKSwgeW91IGNhbiBpbiBmYWN0IGNoYW5nZSB0
aGUgZ2xvYmFsIGRlcmVmZXJlbmNlZCBkYXRhLiBTbyBteSBhbnN3ZXJccGFyDQp0byB5b3VyIHF1
ZXN0aW9uIGlzICdZZXMnIC0gaWYgeW91IHBhc3NlZCBhIHBvaW50ZXIgYXMgYW4gSU4gcGFyYW1l
dGVyIHlvdVxwYXINCmNvdWxkIGNoYW5nZSB0aGUgZGVyZWZlcmVuY2VkIGRhdGEuIFdoYXQgeW91
IGNvdWxkIG5vdCBkbyBpcyBtb2RpZnkgdGhlXHBhcg0KcG9pbnRlciBpdHNlbGYuXHBhcg0KXHBh
cg0KTk9URTogSSBzdGF0ZWQgYWJvdmUgdGhhdCBJTiBwYXJhbWV0ZXJzIGFyZSAqdXNlZCogYXMg
dmFsdWUgcGFyYW1ldGVycyAtXHBhcg0Kd2hldGhlciB0aGUgY29tcGlsZXIgd3JpdGVyICppbXBs
ZW1lbnRzKiB0aGVtIGFzIHZhbHVlLCByZWZlcmVyZW5jZSBvclxwYXINCndoYXRldmVyIGZvciBl
ZmZpY2llbmN5IHJlYXNvbnMgc2hvdWxkIG5vdCBiZSBzb21ldGhpbmcgdGhhdCB0aGUgcHJvZ3Jh
bW1lclxwYXINCnNob3VsZCBuZWVkIHRvIGJlIGF3YXJlIG9mIC0gYXMgbG9uZyBhcyB0aGUgcGFy
YW1ldGVycyAqYmVoYXZlKiBhcyBkZWZpbmVkKS5ccGFyDQpccGFyDQpQYXNzaW5nIGEgcG9pbnRl
ciBhcyBhbiBJTiBwYXJhbWV0ZXIgY291bGQgYmUgdmlld2VkIGFzIGFub3RoZXIgZXhhbXBsZSBv
ZlxwYXINCnNpZGUtZWZmZWN0cy4gSSBoYXZlIG5vdCBiZWVuIGFibGUgdG8gdGhpbmsgb2YgYSBm
ZWFzaWJsZSB3YXkgdG8gcHJvdGVjdCBJTlxwYXINCnBhcmFtZXRlcnMgZnJvbSBtb2RpZmljYXRp
b24gYnkgc2lkZS1lZmZlY3RzIGFzIHNob3duIGJ5IFJvYmVydCBDYW1wYmVsbCBpblxwYXINCmhp
cyBIb3JyaWJsZSBleGFtcGxlIHJlY2VudGx5LiBIb3dldmVyLCBhIGRpZmZlcmVudCBleGFtcGxl
IGFsc28gc2hvd3MgdGhhdFxwYXINCklOIHBhcmFtZXRlcnMgYXMgY3VycmVudGx5IGltcGxlbWVu
dGVkIGluIEJsYWNrQm94IGNhbiBhbHNvIGJlIG1vZGlmaWVkIHZpYVxwYXINCnNpZGUtZWZmZWN0
cy4gQWxsIHlvdSBoYXZlIHRvIGRvIGlzIHBhc3MgdGhlIHNhbWUgdmFyaWFibGUgdG8gdHdvIGRp
ZmZlcmVudFxwYXINCnBhcmFtZXRlcnMgaW4gdGhlIG9uZSBwcm9jZWR1cmU6XHBhcg0KIFxwYXIN
ClxwYXINCk1PRFVMRSBUZXN0R2hhc3RseTtccGFyDQpccGFyDQpJTVBPUlRccGFyDQogIE91dDtc
cGFyDQpccGFyDQpWQVJccGFyDQogIHMxLCBzMjogQVJSQVkgMjAgT0YgQ0hBUjtccGFyDQpccGFy
DQpQUk9DRURVUkUgQ2FwQW5kQ29uY2F0IChWQVIgc3ZhcjogQVJSQVkgT0YgQ0hBUjsgSU4gc2lu
OiBccGFyDQpBUlJBWSBPRiBDSEFSKTsgQkVHSU5ccGFyDQogIHN2YXJbMF0gOj0gQ0FQKHN2YXJb
MF0pO1xwYXINCiAgc3ZhciA6PSBzdmFyICsgc2luO1xwYXINCkVORCBDYXBBbmRDb25jYXQ7XHBh
cg0KXHBhcg0KUFJPQ0VEVVJFIERvKjtccGFyDQpCRUdJTlxwYXINCiAgczEgOj0gIndhZ2dhIjtc
cGFyDQogIHMyIDo9ICJ3YWdnYSI7XHBhcg0KICBDYXBBbmRDb25jYXQoczEsIHMyKTtccGFyDQog
IE91dC5TdHJpbmcoczEpO1xwYXINCiAgT3V0LkxuO1xwYXINClxwYXINCiAgczEgOj0gIndhZ2dh
IjtccGFyDQogIENhcEFuZENvbmNhdChzMSwgczEpO1xwYXINCiAgT3V0LlN0cmluZyhzMSk7XHBh
cg0KICBPdXQuTG5ccGFyDQpFTkQgRG87XHBhcg0KIFxwYXINCkVORCBUZXN0R2hhc3RseS5ccGFy
DQpccGFyDQpccGFyDQpDb25zZXF1ZW50bHksIHRoZSAqcG9zc2liaWxpdHkqIG9mIHNpZGUgZWZm
ZWN0cyBzaG91bGQgbm90IGJlIGFjY2VwdGFibGUgYXNccGFyDQphbiBleGN1c2UgZm9yIG5vdCBl
eHRlbmRpbmcgdGhlIHVzZSBvZiBJTiBwYXJhbWV0ZXJzIHRvIGFsbCBkYXRhIHR5cGVzLlxwYXIN
ClxwYXINClJlZ2FyZHMsXHBhcg0KQ2hyaXMgQnVycm93c1xwYXINCkNGQiBTb2Z0d2FyZVxwYXIN
Cmh0dHA6Ly93d3cuY2Zic29mdHdhcmUuY29tL2NwXHBhcg0KXHBhcg0KXHBhcg0KLS0tLVxwYXIN
ClRvIHVuc3Vic2NyaWJlLCBzZW5kIGEgbWVzc2FnZSB3aXRoIGJvZHkgIlNJR05PRkYgQkxBQ0tC
T1giIHRvIExJU1RTRVJWQExJU1RTLk9CRVJPTi5DSFx9fQDUKAE=
----boundary-LibPST-iamunique-1249685419_-_---

Received on Wed Feb 20 2008 - 00:41:57 UTC